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Technoblabla 

Három kiadott lapszámmal a hátunk mö- 

gött (szeptember, .net különszám, októ- 

ber) igen jelentős múlttal rendelkező lap- 
pá váltunk. Rengeteg témáról írtunk az 
. eddig megjelent több mint 150 oldalon. 

Egyik közeli ismerősöm (aki annyira köze- 

li, hogy őszinte mer lenni) meg is kérdez- 

te, hogy ha ilyen ütemben haladunk, va- 

jon mikorra fogyunk ki a témából? Mit le- 

het még mondani a Window 2000-ről, és a 

.net Enterprise családról? 

Nos, a közeljövőben szeretnénk írni a 
Lightweight Directory Access Protocolról (LDAP), az Encrypting 
File Systemről (EFS), a hálózati adatfolyam-titkosítás szabvá- 
nyos megoldásáról, az IPSecről, szeretnénk egy kicsit felderíte- 
ni az NTFS rejtelmeit; hisz sokat változott az elmúlt verzió óta. 
Míg a Windows 2000 bétaváltozataiban még szerepelt az Auto- 
matic System Recovery (ARS), mellyel elvileg egyetlen varázs- 
flopi segítségével vissza lehetett volna állítani elhalt operáci- 
ós rendszerünket, a végleges termékben már megint az ügyet- 
len Emergency Repair Disk (ERD) szerepel, de most már hasz- 
nálható módon. Nincs többé SP issue! 

Napjaink nyitott hálózataiban roppant fontos a megfelelő tit- 
kosítási algoritmusok használata. A nyílt kulcsú titkosítás nem 
képzelhető el a Ronald Rivest, Adi Shamir és Leonard Adleman 
matematikusokról elnevezett RSA algoritmus nélkül, melyet ér- 
demes legalább egyszer az életben végigküzdeni, mert utána 
az ember büszkén nézhet magára: ezt is értem! 

Biztosan sokan találkoztak már a 169.254.0.0 IP címtarto- 
mányba eső címekkel, melyet az operációs rendszer , csak úgy" 
magáévá tett. Itt az automatikus IP cím felvétellel (APIPA) 
van dolgunk, de hogyan is működik? 

Sokakat fog érinteni az X.500 alapú címtárak replikációja, hisz 
az Active Directoryt sok vállalatnál össze kell kötni Novell NDS- 
sel, vagy valamilyen UNIX-on futó X.500 címtárral. Ilyenkor 
jön jól az LDIF protokoll ismerete. 

A távoli eljáráshívás, Remote Procedure Call (RPC) ugyan 
nem új technológia, de mélyebb ismerete meg nem árthat, 
hisz könnyebben fogjuk venni az , RPC Service is unavailab- 
le" néven ismert akadályt. 

Nagyvállalati környezetben a Windows for Workgroupsnál be- 
vezetett egyenrangú hálózat remekül szolgálta ki a 10-12 fős 
munkacsoportokat, hisz minden gépen meg lehetett osztani a 
fontos könyvtárakat, és végre meg lehetett szabadulni a flopis 
adatátviteltől. Ugyanakkor ha egy vállalatnál nem 12, hanem 
612 gép osztja meg erőforrásait, azt káosznak hívjuk. Ezen a 
problémán segít a vállalati megosztott erőforrások egységes 
faszerkezetbe rendelésével, felfűzésével a Distributed File Sy- 
stem (DFS), mely ráadásul hibatűrő képességgel is felruházha- 
tóvá teszi a fájlkiszolgálókat. Hogyan? 

Ugyanide tartozik a megosztásoknál elsődlegesen használt 
Server Message Block (SMB) protokoll, mely nemcsak 
Windowsos környezetben használható, hanem UNIX-okon is, 
hisz a Samba Serverek SaMBa kiszolgálók. Még Windows 2000 
tartományba is betehetjük őket, ha...!? 





Marcell főszerkesztő 


A Windows 2000-rel elérkeztünk a PnP operációs rendszerek 
korába. Ha ez csak annyit jelent(ene), hogy végre szabadon 
klónozhatjuk a tökéletesre csiszolt operációs rendszer tőpél- 
dányt, már megérte (volna). De ennél sokkal többről van szó. 
A PnP összenő az ACPI-val, hibernálást, standby üzemmódot, 
és egyéb hasznos szolgáltatásokat kínálva mindenkinek. Már 
csak egy lépés hiányzik a gyönyörhöz, az OnNow technológia, 
ami lehetővé fogja tenni, hogy a bekapcsolás után ne kelljen 
öt percet várni, amíg a gép magához tér, hanem azonnal hasz- 
nálatba lehessen venni, mint most egy televíziót. 

Security Configuration Manager. Ezzel lehet tűélesre állítani a vál- 
lalat számítógépein a biztonsági beállításokat. Olyannyira, hogy ha 
ügyetlenek vagyunk, eljuthatunk a használhatatlanul biztonságos 
számítógépig, mely süket és vak, de feltörni sem lehet, az biztos! 
Ezzel szinte egy időben, mondhatni az előzőekkel párhuzamo- 
san fog elkészülni APM, WMI, SMP, NCP, OoS, L2TP, HTTP, 
IMAP, TCP/IP, SCE, IGMP, LanMan, ADSI, 4GT és UDP, BAP, 
NFS, LDIFDE, NBTSTAT, COM--, S/MIME, RSVP, CHAP, RIS, HMAC 
elemző cikkünk. 

De természetesen nem fogunk megfeledkezni olyan fontos 
technológiákról sem, mint a RAID, ActiveX, SMTP, USB, ARP, 
SSL, TLS, DDNS, AWE, TGT, SAM, XML. 

Műhelymunka szintjén még az idén terítékre kerülhet a SIS, 
IrDA, TAPI, PPP, MD5, KDC, SNMP, MMC, ICMP, WSH, PAE, bár 
valószínűleg cikk formájában nem fogunk elkészülni vele. 
Azután jó néhány cikket, mi több egész cikksorozatot érdemel 
az ISAKMP, KMS, NTLM, RIP, NAT, Kerberos, WINS, ACPI, PPTP, 
LPD, VBS, NDIS, ADO, OSPF, NWLink, ASP, MSMO, SCSI, GPO, 
RADIUS, MAPI. 

Ezekkel folyamatosan fogunk megjelenni a megfelelő ro- 
vatok hasábjain. 

És végül, de nem utolsó sorban írni fogunk az SHA, GC, POP3, 
FSMO, PAP, WebDAV, SID, BOOTP, VPN, IXFR, USN, FTP, CSVDE, 
MFT, X.500, DHCP, TGS, SNTP, GRE, SLIP, HTML, GDI, UTF-8, JA- 
VA, CA, RAS, NetBIOS, IAS, BIND, PKCS technológiákról, vala- 
mint az Extensible Authentication Protocol (EAP)-ról. 

RFC rovatunk pedig már van is :-) 

Ezek lennének rövid-, közép-, és hosszútávú céljaink. Tehát a 
kérdés nem az, hogy miről fogunk írni, hanem inkább az, hogy 
meddig tudjuk 48 oldalba zsúfolni havi 64 oldalnyi anyagunkat? 


Fóti Marcell 
MCT, MCSE, MCDBA 
marcellf onetacademia.net 
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HÍREK 


Jövőre megváltozik a Solution Provider prog- 
ram. 
Olyannyira, hogy a neve is más lesz: Microsoft 
Certified Partner lesz az új hivatalos megneve- 
zés. Az új csatlakozási feltételekkel párhuza- 
mosan a Microsoft ígéretei szerint a partnerek- 
nek nyújtott szakmai támogatás is megválto- 
zik, hogy minél több partnercég vehessen részt 
a .NET stratégia sikerében. Az eredeti Solution 
Provider program 1992 óta működik, napjainkban vi- 
lágszerte 31 ezer cég él a partnerség adta lehetőségekkel. 





Minden előzetes várakozással és híreszteléssel ellentét- 
ben megjelent a Windows NT 4.0-ra telepíthető Active 
Directory ügyfélszoftver! 

A kiadott, letölthető szoftver a következő fontos szolgáltatá- 

sokkal rendelkezik: 

-0 Telephelyek figyelembe vétele (Site Awareness) , mellyel 
a munkaállomás mindig a legközelebb eső tartományve- 
zérlőnél jelentkezik be 

2 Jelszóállítás tetszőleges DC elérhetősége esetén (nem 
vár a PDC-re, ha az nem elérhető) 

0 Active Directory Services Interface (ADSI) parancsfájlok 
futtatási lehetősége 

"2 DFS hibatűrést kihasználó ügyfél, mely képes áttérni a 
DFS által megadott tartalék fájlmegosztás használatára, 
ha az elsődleges kiesik 

"0 Active Directory Windows Address Book (WAB) tulajdon- 
ságlapok kezelése. A címjegyzéken véghezvitt módosítá- 
sok (megfelelő jogosultságok esetén) bekerülhetnek az 
Active Directoryba 

"2 Az Active Directory sémamódosítások által igényelt fel- 
használói felület módosítások (display specifiers) is ráte- 
lepíthetők, így NT 4.0-ról is elvégezhető a címtár karban- 
tartása. 

"8 NTLAN Manager version 2 hitelesítés. Lásd cikkünket a 
29. oldalon 

Ugyanakkor meg kell jegyeznünk, hogy e kiegészítő telepítése 

után sem válik a víz vérré - nem lesz az NT 4.0-ból hirtelen 

Windows 2000 Professional. Nem lesz elérhető továbbra sem: 

0 A Kerberos bejelentkezés 

"0 A csoportos házirend (Group Policy) nem értékelődik ki 

"0 Nincs Intellimirror 

2 Nincs IPSEC és L2TP támogatás 

Ezen hiányosságok ellenére is nyújt azonban jó pár fontos 

megoldást, így érdemes lehet letölteni az alábbi címről (lap- 

zártakkor Beta változatban): 

http://www.microsoi m/WINDOWS2000, 


adclients/default.asp 


Hackerek hatoltak be a Microsoft belső hálózatába 

A hazai sajtóban is megjelent a hír a Microsoft belső hálóza- 
tán észlelt rendellenes ténykedésről. A Microsoft biztonsági 
csapata október 14-én észlelte a behatolást, és figyelemmel 
kísérte a hacker lépéseit, melyek arra utaltak, hogy kísérletet 
tesz a belsőbb hálózatok elérésére is. A nyomozás folytató- 
dik, de az már bizonyos, hogy a behatolást nem valamelyik 


Microsoft kiszolgálótermék biztonsági hibája, hanem emberi 
mulasztás okozta. A támadó úgynevezett féregprogramot 
(OAZ worm, közismert fájltörlő és jelszólopó program) küldött 
el az egyik gyanútlan alkalmazottnak, aki a csatolt fájl elindí- 
tásával megfertőzte saját gépét. A worm ezután a felhasználó 
jogosultságaival élve tevékenykedett a hálózaton. A korábbi 
bejelentésekkel ellentétben nincs bizonyíték arra, hogy a for- 
ráskódokhoz bárki hozzáfért volna. A Microsoft szorosan 
együttműködik az USA hatóságaival a nyomozás lefolytatásá- 
ban. 


Már megint új kiszolgálótermék: TAHOE 

A magyarul kicsit tahó hangzású terméknév mögött igazi új- 

donság rejlik: valódi portál és dokumentumkezelő alkalmazás 

van születőben! Félre veled NTFS! A terméket a későbbiekben 
részletesen is ismertetjük, most azonban lássunk egy-két ré- 
gen várt szolgáltatást! 

-2 Portálfunkciók: szabad keresés, és navigálás a publikált 
dokumentumok között. Ha ez idáig nem túl meggyőző, 
hadd említsem meg az előfizetési/feliratkozási lehetősé- 
get, amely arra szolgál, hogy a Tahoe emailben kiértesít- 
sen, ha egy mappában változás történik, például új do- 
kumentum születik. 

"2  Dokumentumkezelés: verziókövetés, dokumentum-élet- 
ciklus kezelés, check-in, check-out műveletek a doku- 
mentumtár egységességének, ellentmondás-mentességé- 
nek fenntartására. A dokumentumok tetszőleges tulaj- 
donságainak (szerző és egyebek) megjelenítése a könyv- 
tárlistákban 

A Tahoe Server alatt ugyanaz a Web Storage Engine dolgozik, 

mint amelyre az Exchange 2000 is épül. 


Mi lesz az SMS sorsa? 

A ma elérhető Systems Management Server utódaként fog 
megjelenni valamikor 2001 közepe táján a Microsoft új rend- 
szerfelügyeleti terméke, a Microsoft Operations Management 
nevű termék, mely a ma elérhető szolgáltatások körét kiegé- 
szíti a realtime adatokon alapuló elemzés képességével. Eh- 
hez a Microsoft megállapodást kötött a NetIO céggel, akiknek 
már van Windows 2000-re készített realtime felügyeleti meg- 
oldásuk. A termék piacra lépése azért esik a távoli jövőbe, 
mert nem csupán a különféle termékekben meglévő felügye- 
leti szolgáltatások összeborításáról van szó, hanem ezek in- 
tegrációjáról és a .NET kiszolgálókkal történő illesztéséről is. 
A .NET Management Services segítségével a meglévő rend- 
szerfelügyeleti funkciók (WMI,MMC) elérhetőek lesznek háló- 
zaton, XML felületen keresztül is. Ezáltal az SMS utóda fejlesz- 
tési platformmá válik, melyhez az eddigieknél lényegesen 
egyszerűbb lesz külső gyártóknak kiegészítéseket írniuk. En- 
nek a folyamatnak az elősegítésére jött létre a Microsoft Ma- 
nagement Alliance szervezet, melynek feladata technikai- és 
marketingtámogatás nyújtása a rendszerüket a .NET Manage- 
ment Services felé megnyitó alkalmazásfejlesztők számára. 
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...És még egy új kiszolgálótermék: a Mobile Informati- 
on Server 

Erről a kiszolgálótermékről egyelőre nem lehet sokat tudni, 
de az bizonyos, hogy célja a vállalati hálózatok elérhetősé- 
gének biztosítása mobil kommunikációs készülékek segítsé- 
gével. Hogy mik ezek az eszközök, azt ne firtassuk, s hogy 
mik is lennének a telefonon elérhető szolgáltatások, azt is 
inkább csak találgassuk: ugye jó lenne az elektronikus leve- 
lezés használata? Hát a névjegyek és naptári bejegyzések el- 
érése? A madarak csicsergéséből az Outlook Mobile Access 
(OMA) szavakat vélem kihallani :) De amint a Microsoft 
weblapján található technikai leírás mondja: az OMA csak a 
jéghegy csúcsa. Kár, hogy nem látunk a vízfelszín alá! 


Whistler 

Október 31-én a Microsoft bejelentette, hogy bétaváltozatban 
elkészült a Windows 2000 utóda, a jelenleg Whistler kódnéven 
futó Windows.NET, Tudjuk, hogy sok vállalatnál éppen csak 
belefogtak a Windows 2000-re történő átállásba. Számukra ta- 
lán megnyugtató hír, hogy a terméket csak 2001 második fé- 


dstra R 


Értsd meg, főnök, a gép 
árába be kell kalkulálni 
az operációs rendszer 
árát is! 


Az szoft- 


tech.net előfizetés: 


Ha szeretné, hogy magazinunk minden hónapban 
biztosan megjelenjen postaládájában, fizessen elő! 
Az előfizetési akciónkról érdeklődjön a oldalunkon, a 











lévére ígérik, és ez az időpont szokásosan csúszni fog. A Beta 
1 általában inkább csak gondolatfoszlánynak tekintendő, 
mintsem terméknek. Élesen emlékszem a Windows NT 5.0 Beta 
1-re (a Windows 2000 ,, leánykori neve") , mely annyira hason- 
lított a Windows NT 4.0-ra - hogy az is volt, csak rá lehetett 
telepíteni az Active Directory egy korai verzióját. 


És egy hír saját házunk tájáról 

NetAcademia - AdAstra együttmőködés 

A NetAcademia Kft. Sikeresen leszerződtette a jövő évadra az 
AdAstra Rt. munkatársait, hogy egy kis színt vigyenek a lap 
egysíkú illusztrálásába. Az AdAstra egy kitalált cég, ahol a 
dolgozók mindennapját áthatja az informatika. A , kollégá- 
kat" Pepe, a http://rajz.lap.hu főszerkesztője alkotta szá- 
munkra. A decemberi számtól kezdve minden hónapban be- 
pillantást nyerhetünk a cég zaklatott informatikai életébe. 
A vállalat szervezeti felépítését itt tekinthetik meg: 
http: hnet.n mia.n r 


Hát mi a francnak tartalak 
benneteket?! Írjatok egyet!! 


Tulajdonkép- 
pen, igen. 


7 Bi B ölláátr- ésén §-i 
2000 10. 
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WINDOWS 
Domain 


Windows 2000 DNS 
Ahhoz, hogy a hálózati számítógépek TCP/IP 
nyelven beszélgethessenek egymással, mind- 

egyikükhöz egyedi IP címet kell rendelnünk. 
Míg a gépek számára ezek használata a legke- 
vésbé sem jelent gondot, az embereknek hamar 
meggyűlik vele a baja. A felhasználók szemszö- 
géből a kommunikáció akkor hatékony, ha a számí- 
tógépekre nevekkel hivatkozhatnak, miközben azok 
továbbra is az IP címüket használják egymás közt. 
A mai Internet őse, az ARPANET kezdetben néhány számí- 
tógépből álló hálózat volt, melyek nevét és IP címeit egyet- 
lenegy szövegfáljban, az úgynevezett HOSTS.TXT-ben tar- 
tották nyilván. A Network Information Center (NIC) frissí- 
tette az összes számítógép nevét és címét a változásokról 
beérkező elektronikus levelek alapján. Az ARPANET fel- 
használói ezután FTP protokollal letölthették a legfrissebb 

HOSTS.TAT fájlt. 

Az ARPANET növekedése rávilágított arra, hogy ez a mód- 

szer nem méretezhető: 

I A HOSTS.TAT fájl terjesztése az ARPANET-hez kapcso- 
lódó gépek számának négyzetével arányos sávszé- 
lességet igényelt. Mivel a gépek száma exponenciálisan 
növekedett, nyilvánvaló lett, hogy ezt a terhelést 
egyetlen számítógép nem bírja el. 

2 Az ARPANET-en két számítógép nem vehetett fel 
azonos nevet. A gépek számának növekedésével a sta- 
tikus, hierarchiát nélkülöző HOSTS.TXT fájl miatt meg- 
nőtt az azonos nevek kiadásának kockázata, és a köz- 
ponti nyilvántartás is egyre nehezeb- 
bé vált. 

"0 A hálózat természete megváltozott: 





zi a 
az ARPANET egykori nagy, időosztá- tása 
sos számítógépeit felváltották a mun- — , számi IE TD 
kaállomásokból álló hálózatok, ame- 181 
lyek mindegyikének egyedi nevet kel- 107 


lett viselnie. Ennek kezelése közpon- 

tilag nem lett volna megoldható. 
Jobb megoldást kellett találni. Számos in- 
dítvány született a hierarchikus névteret használó, elosztott 
névszolgáltatásra. Megszületett a 882-es és a 883-as RFC, 
amelyek leírják az általános erőforrásadatokat tartalmazó, 
elosztott adatbázisra épülő tartomány névrendszer (Domain 
Name System - DNS) felépítését. A további fejlődés miatt 
kiadták az 1034-es és az 1035-ös RFC-t, amelyek az Inter- 
neten ma is használt DNS leírását tartalmazzák. A DNS folya- 
matosan fejlődik - e sorok írásakor is több fejlesztési javas- 
lat tárgyalása folyik. 


A Windows 2000 DNS áttekintése 

A számítógépek közötti kommunikációt elősegíti, ha a számító- 
gépeknek ugyanabból a névtérből adunk nevet, amely egyben 
meghatározza a névadás szabályait és a nevek IP címmé törté- 
nő átalakításának módját. Ahhoz, hogy a számítógépek megszó- 
líthassák egymást, a neveket IP címekkel kell helyettesíteniük, 
amit a névlekérdező szolgáltatás segítségével végeznek el. 

A Windows 2000 két fő névteret és névátalakítási módszert 
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használ: a Windows Internet Naming Service (WINS) szol- 
gáltatással megvalósított NETBIOS-t és a cikk témáját adó 
DNS-t. A Windows 2000 más névtereket is támogat, példá- 
ul a Novell Netware-t és Banyan Vines-t. 


Mi a DNS? 

A DNS az IETF névszolgáltatási szabványán alapuló szolgál- 

tatás, amellyel a hálózati számítógépek megvalósíthatják a 

DNS tartománynevek bejegyzését és átalakítását. Ezeket a 

neveket használjuk például az Internethez csatlakozó szá- 

mítógépek erőforrásainak kereséséhez és használatához is. 

A DNS három fő alkotórészből áll: 

"2 A tartomány névtér és a kapcsolódó erőforrásrekordok 
elosztott nevekre vonatkozó adatbázist alkotnak. 

-2 A DNS névkiszolgálók tárolják a tartománynévteret és 
az erőforrásrekordokat, továbbá válaszolnak a DNS ügy- 
felek kérdéseire. 

"1 A DNS ügyfelek részét képező DNS lekérdezők (resolver) 
felveszik a kapcsolatot a névkiszolgálókkal, és névlekér- 
dezéseket küldenek, hogy hozzájussanak az erőforrásre- 
kordokhoz - az IP címekhez. 


A legfontosabb alapfogalmak 

Tartománynévtér 

A tartománynévtér hierarchikus, faszerkezetű. A DNS név- 
térben a tartománynévtér fájának minden csomópontja és 
levele egy névvel ellátott tartományt jelöl. Minden tarto- 
mánynak lehetnek gyermektartományai. Az alábbi ábrán az 
Internet tartománynévterének szerkezete látható. 
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Az Internet tartománynévtere 


Az ábra szerint a DNS fa minden csomópontjának saját neve, 
illetve az 1034-es RFC szóhasználatával élve címkéje van. A 
DNS címkék hossza 1-63 karakter lehet - kivétel a gyökértar- 
tomány (root) neve, melynek hossza nulla karakter. 

Egy csomópont tartományneve a fa gyökerétől a csomó- 
pontig tartó útvonal címkéiből tevődik össze, amelyeket 
megállapodás szerint balról jobbra, a gyökértől legtávolab- 
bi címkével kezdve olvasunk, az eredményt pedig teljes tar- 
tománynévnek (Fully Oualified Domain Name - FODN) hív- 
juk (például www. falatrax.hu) . 

A tartománynevekben szerepelhetnek kis- és nagybetűk is, 
de az 1034-es RFC-nek megfelelően ezt egyetlen DNS műve- 
let sem veszi figyelembe. A www.falatrax.hu, WwW.FalAT- 
raX.Hu és a WWW.FALATRAX.HU tehát a tartománynév-mű- 
veletek szempontjából azonosak. 


(Ae lolo kán hul 
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Elsőszintű tartománynév 

Az elsőszintű tartománynevek közvetlenül a gyökér alatt 

helyezkednek el. Az előző ábrán is látható, hogy több ilyen 

tartomány létezik, de a továbbiak létrehozása - legalábbis 
az Interneten - nem egyszerű feladat. Az elsőszintű tarto- 
mánynevek három csoportba sorolhatók: 

"2 Az ,ARPA" különleges tartomány, ma már csak fordított 
névlekérdezésre használjuk. 

2 A hárombetűs tartományneveket az 1591-es RFC definiál- 
ja. Jelenleg az alábbi táblázatban látható hét név lé- 
tezik, de a fokozott igény miatt a számuk a jövőben 
várhatóan nőni fog. 


0 Arkétbetűs tartománynevek megegyeznek az Internati- 
onal Organization for Standardization (ISO) országne- 
veivel, és elsősorban az Egyesült Államokon kívüli szer- 
vezetek használják. Az egyetlen kivétel az Egyesült Ki- 
rályság, amelynek jele az ISO szerint GB, az Interneten 
mégis a .uk honosodott meg. 

tartománynév felhasználási kör 

com üzleti tevékenységet folytató szervezetek 
(a Microsofté például microsoft.com) 

edu oktatási intézmények, elsősorban négyéves 
főiskolák és egyetemek (a Carnegie 
Mellon University-é például cmu.edu) 

gov USA szövetségi kormányügynökségek (az 
FBI-é például fbi.gov) 

int nemzetközi egyezmények alapján létrejött 
szervezetek (például a NATO-é nato.int) 

mil katonai célú tartomány az Egyesült Álla- 
mokban (a US Air Force-é például af.mil) 

net Internettel foglalkozó szervezeteket, Inter- 
net- és hálózat-szolgáltatókat stb. takar 
(az InterNIC-é például internic.net) 

org egyéb" kategória, például nem kormány- 


zati vagy nonprofit szervezetek (Reikiről 
például a reiki.org címen olvashatunk) 


Az Internet hárombetűs tartománynevei 


Erőforrásrekordok 

Az erőforrásrekordok a DNS adatbázisban tárolt tar- 
tományok adatait tartalmazzák, amit DNS ügyfelek hasz- 
nálnak. Egy gép címrekordjából például kiderül az IP címe. 
Az alábbi ábrán a www.falatrax.hu névhez tartozó IP címet 
(1.1.1.1) láthatjuk Windows 2000 DNS Szerveren. Az A re- 
kordok Host néven szerepelnek. 
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A DNS kiszolgálók azoknak a tartományoknak az erőforrás- 
rekordjait tárolják, amelyekért felelősek, illetve amelyekre 
vonatkozó kérdéseket képesek megválaszolni. Ha egy DNS 
kiszolgáló a DNS névtér bizonyos részéért felelős, akkor az 
erre vonatkozó adatok hitelességét a kiszolgáló rendszer- 
gazdájának kell biztosítani. A hatékonyság növelése érde- 
kében a DNS kiszolgálók a tartományfa bármely részének 
erőforrásrekordjait képesek ideiglenesen tárolni. 

Az 1035-ös, 1036-os és még néhány későbbi RFC több erőfor- 
rásrekord-típust határoz meg. Bár ezek többségét már nem 
használjuk, a Windows 2000 még támogatja alkalmazásukat. 
Az alábbi ábrán az igen híres Andrew File System Database 
(AFSDB) erőforrásrekord látható, több másik ismeretlen re- 
korddal egyetemben, amelyeket valószínűleg ijesztgetés cél- 
jából, kollégáink megtréfálására tudunk csak felhasználni :-) 





Az alábbi táblázat felsorolja azokat a rekord-típusokat, ame- 
lyek leginkább elképzelhetők egy Windows 2000 hálózatban. 


felhasználás 
Munkaállomás IP címe. 


rekordtípus 
A: cím (host Address) 





CNAME: alias 


MX: levelezés-szervező 
(Mail eXchanger) 


NS: névkiszolgáló 
(Name Server) 


PTR: mutató (PoinTeR) 


SOA: felelősség 
kezdete 

(Start Of Authority) 
SRV: szolgáltatás- 
azonosító (SeRVice 
locator) 


Egy munkaállomáshoz több név is (Ca 
nonical NAME) tartozhat. 

Az elektronikus leveleket levelezéski- 
szolgálóhoz, illetve ha nem elérhető, 
pótkiszolgáló(k) hoz irányítja. 
Felsorolja a tartományért, illetve a de- 
legált altartományért felelős DNS 
kiszolgálókat. 

Fordított névátalakítás az inaddr.arpa 
tartománnyal. 

Meghatározza a zóna elsődleges DNS ki- 
szolgálóját és egyéb jellemzőket is. 


Megmutatja, hogy adott szolgáltatás 
melyik kiszolgálón fut. Az Active Direc- 
tory SRV bejegyzéseket használ a tarto- 
mányvezérlők, a globális katalógus és az 
LDAP kiszolgálók azonosítására. 
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A leggyakoribb erőforrásrekord-típusok 

Bár erőforrásrekordok a DNS fa bármely csomópontjához 
hozzárendelhetők, egyes típusok több tartományban egy- 
általán nem szerepelnek (PTR bejegyzés például csak az in- 
addr.arpa alatti tartományokban található) . A felsőbb szin- 
tű tartományoknak (például microsoft.com) saját erőforrás- 
rekordjaik lehetnek (például MX bejegyzés a Microsoftnak 
küldött levelek irányítására) , illetve további altartományok 
kapcsolódhatnak hozzájuk, amelyeknek szintén lehetnek 
saját erőforrásrekordjaik (az eu.microsoft.com altartomány- 
nak például lehet egy www.eu.microsoft.com címrekordja) . 


Alias 

Aliasok segítségével ugyanaz a tartomány többféleképpen 
is elnevezhető. CNAME bejegyzések használata a követke- 
ző esetekben javasolt: 

"Az A pbejegyzéssel megadott számítógépet ugyanabban 
a zónában kell átnevezni. Ha például a gep.falatrax.hu 
nevet masina. falatrax.hu-ra kell változtatni, akkor ké- 
szíthetünk egy CNAME bejegyzést, miszerint a gep.fa- 
latrax.hu a masina.falatrax.hu-ra mutat. 

Egy közismert szolgáltatás, például ftp vagy www, több 
kiszolgálón elosztva fut, így az általános névnek több 
gépre kell mutatnia. Lehet, hogy a gep.falatrax.hu és 
a masina. falatrax.hu nevekhez például egy közös 
www.falatrax.hu aliast szeretnénk rendelni. A felhasz- 
nálók az utóbbit használják, és fogalmuk sem lesz ar- 
ról, hogy a kéréseiket melyik kiszolgáló teljesítette. 
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DNS lekérdezés 

A DNS ügyfél lekérdezi egy DNS kiszolgálótól a megadott 
tartomány egy vagy több erőforrásrekordját, például a fa- 
latrax.hu tartomány A címrekordjait. Ha a tartomány és a 
kért erőforrásrekord létezik, a kiszolgáló DNS válaszüzenet- 
ben küldi vissza a kérésben szereplő adatokat. A DNS vá- 
laszüzenet tartalmazza az eredeti kérést és a kérdéses re- 
kordokat, feltéve, hogy a DNS kiszolgáló hozzá tud jutni a 
szükséges erőforrásrekordokhoz. 

A DNS lekérdezés, vagy az 1034-es RFC szóhasználatával 
élve normál lekérdezés a céltartomány nevét, a lekérdezés 
típusát és osztályát foglalja magában. A lekérdezés azokra 
a rekordokra (akár az összesre) vonatkozik, amelyeket az 
lekérdező szeretne megtudni. 


DNS frissítés 

A DNS frissítést egy DNS ügyfél akkor kéri a DNS kiszolgálótól, 
ha egy adott tartományban új erőforrásrekordot akar létrehoz- 
ni, vagy meglévőt módosítani, illetve törölni. Megváltoztathat- 
juk például a gep.falatrax.hu nevet úgy, hogy a 10.10.1.100 cím- 
re mutasson. Ezt a műveletet dinamikus frissítésnek is hívják. 


DNS zónák 

A DNS névtér bizonyos részét felépítő és karbantartó ki- 
szolgáló felelős a kérdéses névtérrészért, a zónáért, amely 
a DNS replikáció alapegysége is. A zóna tulajdonképpen 
egy fájl, amely egy vagy több DNS tartomány egy vagy 
több erőforrás-rekordját tartalmazza. (A zóna minden ,,ren- 
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des" DNS Serveren egyszerű szövegfájl, míg a Windows 2000 
esetében a zóna tartalma az Active Directoryban is tárolód- 
hat. Mivel a zóna fogalma eléggé ismeretlen a kezdő DNS-ezők 
számára, ezért a cikk hátralévő részébe néha beszúrtam 
hogy ,,...azaz fájl...", amit értsünk úgy, ahogy kell: a zóna- 
fájl mindaddig fájl valahol a merevlemezen, amíg be nem 
küldjük az Active Directoryba. ) 

A Windows 2000 háromfajta zónát támogat: 

2 A standard elsődleges (standard primary) a zóna ere- 
deti példányát tárolja, amit másodlagos zónákba repli- 
kálhat. A zónában történő változások vezetése mindig 
a normál elsődlegesben történik. Ez a zónatípus tehát 
egyszerű szövegfájlokban tárolja a DNS rekordokat. 

I A standard másodlagos (standard secondary) a zónaa- 

datok csak olvasható példányát tárolja, ami növelheti 

a teljesítményt és a rugalmasságot. A Windows 2000 

DNS Szerveren a secondary zónafájl is írhatónak lát- 

szik, mert az írási kéréseket ez a kiszolgáló automati- 

kusan átirányítja az írható példányra (primary). 

Az Active Directoryval integrált zóna a Microsoft saját 

zónatípusa, melynek adatai a Windows 2000 Active Di- 

rectoryban (AD) találhatók, ennek megfelelően a rep- 

likációja AD replikációval valósul meg. 

A zóna eredeti példányát az elsődleges zóna DNS kiszolgá- 

lója tárolja. A zónának itt van egy úgynevezett SOA bejegy- 

zése, amellyel önmagát elsődlegesnek nevezi ki. A teljesít- 
mény és a redundancia fokozására az elsődleges zónaállo- 
mány automatikusan átmásolható másodlagos zónákban lé- 
vő DNS kiszolgálókra. Ha a zónában változás következik be, 
például új A rekord jön létre, akkor az elsődleges zónaállo- 

mány módosul, majd átmásolódik a másodlagos zónákba. A 

zónaállomány átvitele zónareplikációval valósul meg. 

A Windows 2000-ben az első zóna a létrehozásakor csak 

egyetlen DNS tartománynévre (például falatrax.hu) vonat- 

kozó adatokat tartalmaz. Ezután a zónában készíthetünk 
erőforrás-rekordokat kézzel, vagy engedélyezhetjük a tar- 
tomány dinamikus frissítését. 
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Status Running 


Type: Active Directoryintegrated 


Datais stored in Active Directory. 


Allovi dynamic updates? 
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Ha a zóna dinamikus frissítése engedélyezett, akkor a Win- 
dows 2000 munkaállomások közvetlenül képesek módosí- 
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tani a DNS kiszolgáló A és PTR bejegyzéseit. Ha a gép egy- 
ben DHCP ügyfél is, akkor a DHCP kiszolgáló beállítható 
úgy, hogy az frissítsen. 

Ha a zóna elkészült, további altartományokat kapcsolhatunk 
hozzá (például marketing. falatrax.hu) . Ennek oka lehet példá- 
ul az, hogy egy új épület számára akarunk DNS szolgáltatást 
biztosítani, amit a szülőtartománytól elkülönülten kell kezel- 
ni. Az így létrejött altartományban, amely akár egy külön zó- 
nában is lehet, erőforrás-rekordokat kell készíteni (például 
címrekordot a alma. marketing. falatrax.hu számítógépnek). 

Ha a zónát alkotó tartományok valamelyikéhez további tarto- 
mányokat kapcsolunk, ezek tartozhatnak az eredeti vagy má- 
sik zónába (...azaz fájlba. ..), ahogy ez az alábbi ábrán is lát- 
ható. A falatrax.hu alatti marketing.falatrax.hu altartomány 
például lehet ugyanabban, de külön zónában is. Az altar- 
tomány így kezelhető az eredeti zóna részeként, vagy delegál- 
ható egy másik, az altartomány kezelésére létrehozott zónába. 


du om (hm. (go 
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Hr.falatrax.hu zónafájl 


( 6— Falatrax.hu zónafájl 


Zónák és tartományok 


A fenti példában a falatrax.hu tartománynak van egy hr.falat- 
rax.hu és egy marketing. falatrax.hu altartománya is. Mindket- 
tő egy-egy cím-rekorddal rendelkezik. Külön zónában talál- 
hatók, más-más DNS kiszolgálók kezelésében. A gep.falat- 
rax.hu címrekord a falatrax.hu, a masina.hr.falatrax.hu pedig 
a hr.falatrax.hu zónába (...azaz fájlba...) tartozik. 


Active Directory-val integrált zónák 

A Windows 2000 DNS szolgáltatásának egyik legfőbb új- 
donsága, hogy a zónákat képes az AD-ben tárolni. Az AD- 
val integrált zóna elsődleges DNS zóna, amely az AD repli- 
káció segítségével másolódik át más elsődleges AD zónák- 
ba (nem a hagyományos zónaátvitellel). A zónák tárolásá- 
nak ez a módja a Microsoft egyedi megoldása, de több elő- 
nye is van: az ilyen zónák valódi többforrásúak, így a mó- 
dosítások bármelyik DNS kiszolgálón végbemehetnek. Ez 
növelheti a DNS szolgáltatás hibatűrését. Az AD replikáci- 
ónak köszönhetően a zónaállományok átvitele a lassú kap- 
csolatokon keresztül hatékonyabb lehet, mivel az adatok a 
telephelyek között tömörítve utaznak. 
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Figyelem! Az AD integráció és a globális katalógus (GC) 
szerep üti egymást! Erről szól a , DNS Server Generates 
Event 4011 [0252695]" című Knowledge Base cikk, 
mely leírja, hogy ha egy tartományvezérlő egyben glo- 
bális katalógus kiszolgáló is, akkor bizonyos, DDNS re- 
gisztrációt igénylő komponensek előbb indulnak el, 
mint maga a DNS kiszolgáló, emiatt ronda hibaüzenetek 
jelennek meg az Eseménykezelőben rendszerindításkor. 


. Megoldási javaslatok: 


1. A zóna ne legyen AD integrált! 

2. A zóna ne ugyanazon a gépen legyen, és akkor 
lehet AD integrált! 

3. A gép ne legyen GC, és akkor maradhat a zóna 
AD integrált! 


Fordított lekérdezési zónák 

A DNS kiszolgálókhoz érkező kérések legtöbbjében a keresés 
az A címrekordban szereplő DNS néven alapul. Ez a lekérde- 
zéstípus a válaszban IP címet vár, és normál lekérdezésnek 
hívjuk. A DNS fordított lekérdezést is lehetővé tesz, amellyel 
egy IP címhez tartozó nevet kereshetünk meg - például, mi 
a DNS neve a 101.10.1.100 IP című számítógépnek? 

A fordított lekérdezések támogatására egy különleges, in- 
addr.arpa nevű tartományt foglaltak le az Internet DNS 
névteréből. Az altartományok neve az IP címek (tizes szám- 
rendszerbeli) számjegyeiből képződik, fordított sorrendben, 
egymástól ponttal elválasztva. A fordított sorrend szüksé- 
ges, mert bár az IP címeket is balról jobbra olvassuk, de a 
DNS nevekkel ellenkező irányban értelmezzük (balról jobbra 
haladva a cím egyre meghatározottabbá válik). Emiatt az in- 
addr.arpa tartomány építésekor az IP cím oktettjei fordított 
sorrendben követik egymást. A 192.168.100.0 alhálózat for- 
dított lekérdezési zónája például 100.168.192.in-addr.arpa. 
Ezzel a megoldással az in-addr.arpa DNS fa alsóbb ágainak 
kezelése delegálható ahhoz a szervezethez, amelyik a meg- 
felelő IP cím tartományokat megkapja. 

Az in-addr.arpa PTR rekordokat használ, amelyek IP címek- 
hez rendelnek tartományneveket. A normál keresés zónájá- 
ban ezek megfelelői az A címrekordok. A fordított lekérde- 
zés akkor eredményes, ha a mutató érvényes, tehát létezik 
egy hozzárendelt címrekord is. 

Az in-addr.arpa tartományt csak az IPv4 (Internet Protocol 
version 4) protokollal működő hálózatok használják. A Win- 
dows 2000 DNS MMC (Microsoft Management Console) mo- 
duljának New Zone (új zóna) varázslója ezt használja az új, 
fordított keresési zónák elkészítésekor. Az IPv6 (Internet 
Protocol version 6) protokollon alapuló hálózatokban a for- 
dított keresési zónák az ip6.int tartományban találhatók. 


Fordított lekérdezések 


Fordított lekérdezésnél a DNS kiszolgálónak a megadott IP 
címhez tartozó DNS tartománynevet kell válaszként vissza- 
küldenie. A fordított lekérdezések valójában olyan nörmál le- 
kérdezések, amelyek a fordított keresési zónára vonatkoznak. 
A DNS szabvány szerint a fordított lekérdezési zónák és a 
PTR bejegyzések elkészítése nem kötelező. Ennek megfele- 
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lően a Windows 2000-ben sem szükségesek, bár egyes al- 
kalmazások kihasználják a biztonság növelésére. 


Inverz lekérdezések 

Az inverz lekérdezések eredeti leírása az 1032-es RFC-ben 
olvasható, de ez mára elavult. Célja egy IP címhez tartozó 
név megtalálása volt, nem szabványos DNS lekérdezéssel. 
Használata a DNS szolgáltatás ellenőrzését és javítását se- 
gítő NSLOOKUP.EXE korai változataira korlátozódik. A Win- 
dows 2000 DNS kiszolgáló felismeri és elfogadja az inverz 
lekérdezéseket, amelyekre ,hamis" inverz választ küld. 


A DNS lekérdezések típusai 

A DNS lekérdezések két osztályba sorolhatók: rekurzív és 
iteratív lekérdezések. 

A rekurzív lekérdezésre a DNS kiszolgálóknak teljes választ 
kell adniuk, még akkor is, ha ehhez más DNS kiszolgálók 
segítségét is igénybe kell venniük. A teljes válasz elkészí- 
téséhez a kiszolgáló egymást követő iteratív lekérdezése- 
ket küld más DNS kiszolgálóknak a lekérdezést végrehajtó 
számítógép nevében. 

Iteratív lekérdezésnél a kérést küldő számítógép a további 
kiszolgálók igénybevétele nélkül adható legjobb választ 
várja a DNS kiszolgálótól. 

A munkaállomások általában rekurzív lekérdezéseket külde- 
nek; feltételezik, hogy a DNS kiszolgáló vagy tudja a választ, 
vagy képes megkeresni. A DNS kiszolgálók ennek megfelelően 
többnyire iteratív lekérdezéseket küldenek más DNS kiszolgá- 
lóknak, ha a rekurzív lekérdezésekre nem tudják a választ. 


DNS lekérdező 

A DNS lekérdező a Windows 2000 egyik rendszerösszetevő- 
je, amely DNS kiszolgáló(k)nak küld lekérdezéseket. A Win- 
dows 2000 TCP/IP protokollverem beállításakor általában 
megadjuk legalább egy DNS kiszolgáló IP címét, amely- 
(ek)hez a lekérdező a lekérdezéseket elküldi. 

A Windows 2000 lekérdezője a DNS ügyfél eleme, ami a TCP/IP 
protokollal együtt automatikusan települ, és a services.exe fo- 
lyamat részeként fut. Más Windows 2000 szolgáltatásokhoz 
hasonlóan a DNS ügyfél is a System fiókkal jelentkezik be. 


A DNS lekérdező gyorsítótára 

Gyakori eset, hogy egy számítógépnek rendszeresen kap- 
csolatba kell lépnie más számítógépekkel, ezért ugyanan- 
nak a DNS névnek (például a levelezés-kiszolgáló nevének) 
az átalakítását sokszor kellene elvégeznie. Ennek elkerülé- 
sére a Windows 2000 egy különleges gyorsítótárat használ 
a DNS adatok ideiglenes tárolására. 

A DNS ügyfélszolgáltatás a lekérdezésekre kapott válaszok 
erőforrásrekordjait ideiglenesen, a TTL (Time-To-Live) beállí- 
tásnak megfelelő ideig megőrzi. A gyorsítótár adatai felhasz- 
nálhatók a beérkező kérdések megválaszolására. Alapértel- 
mezés szerint a gyorsítótár TTL-je a lekérdezésre kapott vá- 
laszban szereplő TTL értéken alapul. A lekérdezés tárgyát ké- 
pező tartománynévért felelős DNS kiszolgáló határozza meg 
az egyes erőforrásrekordok TTL-jét a válasz elküldése előtt. 





A gyorsítótár tartalma a 
IPCONFIG /DISPLAYDNS 
paranccsal jeleníthető meg. 


Negatív gyorsítótár 

A DNS ügyfélszolgáltatás a hagyományos mellett negatív 
gyorstárazást is végez, ha a lekérdezésben szereplő tartomány- 
névhez nem tartozik erőforrásrekord, vagy egyáltalán nem lé- 
tezik a tartomány. Ekkor a lekérdezés sikertelen volta tároló- 
dik el ideiglenesen, ami megakadályozza a nem létező nevek- 
re vonatkozó ismételt lekérdezéseket. 

Ha egy DNS kiszolgálónak továbbított kérésre negatív válasz 
érkezik, akkor alapértelmezett esetben 5 percig negatív válasz 
érkezik minden olyan lekérdezésre, amely ugyanazt a tarto- 
mánynevet kérdezi. A negatív válaszok a sikereseknél rövidebb 
ideig maradnak a gyorsítótárban, hogy az ott lévő adatok mi- 
nél kevésbé legyenek elavultak. A negatív válaszok tárolási 
ideje szabályozható az alábbi rendszerleíró azonosítóval: 


NegativeCacheTime 

Az azonosító helye: HKEY LOCAL MACHINEV 
SystemiCurrentControlSet Services 
DnscacheNParameters 

Adattípus: REG DWORD-Time, másodpercben 
Alapértelmezett érték: Oxl2c (decimális 
értéke 300 másodpercnek, vagyis 5 perc- 
nek felel meg) 

Értelmezési tartomány: 0—OxXFFFFFFFF (a 
túlságosan elavult bejegyzések elkerülé- 
sére egy napnál kisebb érték javasolt) 
Alapértelmezésben létező azonosító 


A negatív gyorsítótár csökkenti a DNS kiszolgálók terhelé- 
sét, de ha a szóban forgó erőforrásrekordokra később szük- 
ség lesz, újabb lekérdezésekkel megszerezhetők. 

Ha - alapértelmezett esetben 30 másodpercig - egyik DNS 
kiszolgáló sem elérhető, az időkorlátozás helyett a továb- 
bi lekérdezések azonnal hibát eredményeznek. Ezzel időt 
takarítanak meg azok a szolgáltatások, amelyek DNS lekér- 
dezéseket végeznek a rendszertöltés (boot) során. 

A DNS gyorsítótára új szolgáltatás a Windows 2000- 
ben. Sok rendszergazdát az őrületbe is kerget, mivel bi- 
zonyos esetekben megnehezíti a hibakeresést, hiszen 
látszólag hiába javítgatjuk ki gondosan a felfedezett 
DNS hibákat, a javítások mégsem jutnak érvényre. 
Ilyenkor mindig gondoljunk arra, hogy a DNS gyorsító- 
tár még a régi hibás adatokat tartalmazza és sürgősen 
adjuk ki a következő parancsot: 

IPCONFIG /FLUSHDNS 

Na ugye, hogy megy?! 


Zónaátvitel 

A DNS rugalmasságának és teljesítményének fokozására 
minden standard elsődleges zónához legalább egy stan- 
dard másodlagos zónát is érdemes telepíteni, amelynek az 
adatai egy másik DNS kiszolgálón tárolódnak. Az elsődle- 





ges zónában végbemenő változásokat követően a zónaada- 
toknak replikálódniuk kell a másodlagos zónákba: ez a fo- 
lyamat a zónaátvitel. 

A zónaátvitel többnyire automatikusan, a SOA rekordban 
előírt időközönként történik. Kézi vezérléssel is végrehajt- 
ható a DNS MMC modulban, ha gyanítható, hogy a zóna 
frissítése nem megfelelő. 


1.2, Gonsole Window Help ETTE 
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A fenti napló szerint a másodlagos zóna DNS kiszolgálója 
kérdezi az elsődleges zónát, amelyre válaszként a SOA be- 
jegyzés érkezik. A másodlagos zóna megállapítja, hogy a 
verziószám megnőtt az elsődleges DNS kiszolgálón, ezért 
(inkrementális) zónaátvitelt kezdeményez. 

A kézi vezérlésű DNS kiszolgálóknál ez jellemző hibaforrás: az 
elsődleges zónát megváltoztatják, de a verziószámot nem, így 
a replikáció elmarad. A Windows 2000-ben a 
zóna megváltoztatása - történjék akár a DNS 
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MMC modullal, vagy dinamikus bejegyzéssel - 
automatikusan frissíti a verziószámot, így biz- 


DNS EJ ame as parent folder) Startof Auth... [2], platen.net]  tosítja, hogy a verziószám következő ellenőr- 
A BH hofeherke.netacademia. fm (EJ (same as parent folder) NameServer —— platan.netacad ké 3 . 3 
63 CI Forward Lookup Zones E) waw Host 1.1.1.1 zésekor a zónaátvitel bekövetkezzen. 


Növekményes (inkrementális) zónaátvitel 
A nagy zónák átvitele a sávszélesség jelentős 
részét lefoglalhatja, főként lassú, WAN kap- 
csolatok esetén. A zónaátvitel hatékonyságá- 
51 nak növelésére a Windows 2000 új megoldást 
vezetett be a DNS zónák replikálásához: a nö- 





Ha egy Windows 2000 DNS kiszolgálón standard másodla- 
gos zónát létesítünk, akkor oda a standard elsődleges zó- 
na összes erőforrásrekordja átmásolódik. A DNS kiszolgálók 
korai változataiban akkor is végbemegy a teljes zónaátvi- 
tel, ha a másodlagos zóna csak az adatok összehangolását 
kéri az elsődlegestől, ami nagy zónáknál meglehetősen 
időigényes lehet, és a hálózati erőforrások pazarlását is 
magával vonja. Ez fontos kérdés, mert a zónaátvitelre min- 
den olyan alkalommal szükség van, amikor az elsődleges 
zóna megváltozik, például a tartományban egy új címre- 
kordot készítünk, vagy egy meglévőt megváltoztatunk. 

Az erőforrásrekordok replikálását követően az új, standard 
másodlagos zóna DNS kiszolgálója rendszeresen megkérde- 
zi az elsődleges zóna DNS kiszolgálóját, hogy történt-e 
változás. A SOA rekordban meghatározott időközönként el- 
lenőrzi, hogy az elsődleges zóna verziószáma megválto- 
zott-e. Ha nőtt, akkor zónaátvitelt kell végrehajtani. Ezt a 
folyamatot követhetjük nyomon az alábbi Network Monitor 
naplórészletből, ahol a két kommunikáló DNS kiszolgáló a 
már jól ismert GEP és MASINA: 


1 563.890835 Gep Masina DNS 0x6000:Std Ory 
for falatrax.hu. of type SOA on class INET 
addr. 10.10.2.200 10.10.1.200 

2 563.890835 Masina Gep DNS 0x6000:Std Ory 
Resp. for falatrax.hu of type SOA on class 
INET addr. 10.10.1.200 10.10.2.200 

3 563.890835 Gep Masina DNS 0x4000:Std Ory 
for falatrax.hu of type Reg for incrmntl 
zn Xfer on class INET  10.10.2.200 
10.10.1.200 

4 563.890835 Masina Gep DNS 0x4000:Std Ory 
Resp. for falatrax.hu of type SOA on class 
INET addr. 10.10.1.200 10.10.2.200 





vekményes zónaátvitelt, ami nem a teljes zó- 
nát továbbítja, csak a változásokat. Ezzel jelentősen csökken 
a másodlagos zónák aktualitásának megőrzéséhez szükséges 
hálózati forgalom. Leírása az 1995-ös RFC-ben olvasható. 
A növekményes zónaátvitelnél először meg kell határozni a 
zóna forrása és replikált változata közötti különbségeket. 
Ha a zónák SOA bejegyzésében található sorszámok azono- 
sak, nincs szükség zónaátvitelre. 
Ha a forrás verziószáma nagyobb a kérést végrehajtó má- 
sodlagos kiszolgálóénál, akkor a megváltozott erőforrásre- 
kordokból álló zónaátvitel zajlik le. A zónát kezelő DNS ki- 
szolgálónak nyilvántartást kell vezetnie a zóna változásai- 
ról, hogy a növekményes zónaátvitelre vonatkozó kérések- 
nél a változásokat el tudja küldeni. A Windows 2000 a nö- 
vekményes változásokat a Winntiystem32Ndns mappában 
lévő szövegfájlokban tárolja, melyek neve a megfelelő zóna 
adatait tartalmazó fájl nevéből képződik (ez utóbbi a zóna 
készítésekor határozható meg). Ha a falatrax.hu zóna ada- 
tait a falatrax.hu.dns fájlban tároljuk, akkor a növekményes 
frissítés a falatrax.hu.dns.log fájlban lesz naplózva. 


Active Directoryval integrált zóna replikációja 

A standard zónák a hagyományos zónaátvitellel replikálód- 

nak. Az AD-vel integrált zónák ellenben az AD replikációt 

használják a frissítéshez. Ennek előnyei: 

"0 A DNS kiszolgálók többforrásúak. A standard DNS zó- 
náknál az összes változtatást az elsődleges DNS kiszol- 
gálón kellett végrehajtani. Az AD-vel való integráció 
következményeként a változtatások bármelyik DNS ki- 
szolgálón végrehajthatók, ami javítja a teljesítményt, 
a méretezhetőséget és a hibatűrést. 

"8 Az AD replikáció hatékonyabb és gyórsabb: nem a tel- 
jes zónát továbbítja, csak a megváltozott adatokat, így 
a hálózatot is csak ezek terhelik. A telephelyek közti, 
többnyire lassú kapcsolatokon történő replikáció jelen- 
tősen tömöríti az átvitt adatokat. 








WINDOWS 2000 / DOMAIN NAMING SYSTEM 


0 A replikációs topológiát csak egyszer kell megtervezni 
és kivitelezni, ugyanazt használjuk az AD és a DNS vál- 
tozások replikálásakor is. 

Az AD-t használó vállalatoknál javasolt az AD-vel integrált 

zónák alkalmazása. Ha azonban valamelyik külső cég DNS 

kiszolgálóját használják, az nem fogja támogatni ezt a zó- 
natípust. 


Zónadelegáció 
A DNS egy elosztott adatbázis, amit kifejezetten a 
HOSTS.TXT-vel történő névátalakítás korlátainak áthidalá- 
sára hoztak létre. Miért méretezhető a DNS olyan nagy 
névterekre vagy hálózatokra, mint például az Internet? A 
tartománykezelés delegálhatósága miatt. Zó- 
nadelegációról akkor beszélünk, ha a szülő- 
tartomány tulajdonosa az altartomány erő- 
forrásrekordjainak kezelését az altartomány 
tulajdonosára bízza. 
Az Internet első szintű, hárombetűs (például 
.com, .org, .net stb.) és földrajzi (például 
.uk, .jp stb.) tartományneveinek elosztott 
átalakítását 13 gyökérkiszolgáló (A.ROOT- 
SERVERS.NET — M.ROOT-SERVERS.NET) végzi. 
Segítségükkel az Internet számítógépei a 
teljes DNS adatbázishoz hozzáférnek. A gyökér és az első- 
szintű tartományok alatt helyezkednek el a független szer- 
vezetek hatáskörébe tartozó tartományok és altar- 
tományok. Az elsőszintű tartományok közül néhány továb- 
bi hierarchiát mutat. A .hu tartománynak például van co.hu, 
info.hu, org.hu, erotika.hu altartománya, a teljes lista itt 
tekinthető meg: 
http; w.nic. htm 
A delegáció a DNS fa elmetszésével szemléltethető: a met- 
szésvonal alatti tartományért való felelősséget a vonal fe- 
letti tartomány átadja a vonal alattinak. A hr.falatrax.hu 
altartomány a falatrax.hu tartomány alatt helyezkedik el. A 
delegáció eredményeként az alárendelt tartományért másik 
kiszolgáló lesz felelős. 
A delegációhoz a szülőzónában lennie kell A és NS bejegy- 
zésnek, melyek mindegyike a delegált tartomány gyökeré- 
re mutat. A falatrax.hu zónában például lennie kell a hr.fa- 
latrax.hu-ra mutató A és NS bejegyzésnek. A Windows 
2000-ben varázsló könnyíti meg a delegáció létrehozását. 
TETT. alülzi 
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Továbbító (forwarder) és szolga DNS kiszolgáló 

Ha egy lekérdező megszólít egy DNS kiszolgálót, akkor az 
először a saját gyorstárolóját felhasználva próbálja megta- 
lálni a tartománynevet, majd visszaküldeni a megfelelő 
erőforrásrekordokat. Ha ez nem sikerül, a kiszolgáló itera- 
tív lekérdezésekkel próbálja megoldani a feladatot. Az első 
lekérdezést egy gyökérkiszolgálónak küldi el. Ez a módszer 
azonban nem biztos, hogy megfelelő, ha a kiszolgáló egyi- 
ke egy olyan telephely DNS kiszolgálóinak, amely lassú 
kapcsolaton keresztül kommunikál a világgal. 

Az alábbi ábrán látható, hogy a továbbító egy DNS kiszol- 
gáló, amelyhez más DNS kiszolgálók fordulnak, mielőtt a 
szükséges névátalakítást megkísérelnék végrehajtani. 


L] 


Dj 
ú STT len 
"A" DNS kiszolgáló (továbbító) 


külső DNS 


kiszolgálók 


"B" DNS kiszolgáló ev köszolgátó 


rj— LB 


"C" DNS kiszolgáló (továbbító) 


Ha a példában szereplő A, B és C kiszolgálók bármelyike rekur- 
zív lekérdezést hajt végre, először a helyben tárolt zónák vagy 
a gyorsítótár alapján próbálnak választ adni. Ha ez nem sike- 
rül, akkor nem külső DNS kiszolgálókhoz fordulnak, hanem a D 
kiszolgálónak küldik el a kérést, amely nagyobb eséllyel tud 
válaszolni a saját gyorsítótárjából. Ez az elrendezés csökkenti 
a lekérdezések megválaszolásához szükséges külső forgalmat. 
Ha a továbbító (példánkban a D kiszolgáló) nem tud az A, B 
vagy C kiszolgálók kérdésére válaszolni, ez utóbbiak ismét 
maguk próbálják megszerezni a választ, most már iteratív le- 
kérdezésekkel. Ennek a nemkívánatos jelenségnek a kiküszö- 
bölésére találták ki a szolga DNS kiszolgálókat. Ezek olyan 
továbbítók, amelyek a lekérdezéseket csak továbbíthatják. A 
DNS kiszolgálót így arra kényszeríthetjük, hogy minden le- 
kérdezési feladathoz a beállított továbbítókat használják. 


Round robin terheléselosztás 

A round robin módszert a hálózati erőforrások terhelésének 
elosztására használják. Ha egy lekérdezéshez több erőforrás- 
rekord is tartozik, akkor a round robin módszer alkalmazásá- 
nál a válasz mindig a soron következőt tartalmazza - az 
utolsó bejegyzést ismét az első követi. Ez az ügyfélprogra- 
mok által gyakran használt webkiszolgálók és más, többkap- 
csolatos, azaz több hálózati kártyával, illetve IP címmel ren- 
delkező (multihomed) számítógépek terheléselosztásának 
nagyon egyszerű formája. Az alábbi ábrán annak eredménye 
látható, hogy NSLOOKUP paranccsal gyors egymásutánban 
kétszer lekérdeztem a www.microsoft.com IP címét. Megfi- 
gyelhető, hogy noha mindkét esetben négy IP címet kaptam 
vissza, a második lekérdezésnél más a sorrend, így az ügy- 
félalkalmazások másik kiszolgálóra jutottak volna. 
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A round robin csak akkor működhet, ha a lekérdezett név- 
hez a zónában több A címrekord tartozik. 


Dinamikus frissítésű DNS ügyfél 

Nagy hálózatokban az összes erőforrásrekord begyűjtése és 
érvényességük megőrzése komoly feladat lehet. A címre- 
kordok karbantartása akár egy vagy több személy teljes 
munkaidejét is igényelheti. Ennek megkönnyítésére a Win- 
dows 2000 támogatja a DNS dinamikus frissítését, melynek 
részletes leírása a 2136-os RFC-ben olvasható. 

Dinamikus DNS-nél az ügyfél DNS bejegyzési kérelmet küld 
a DNS kiszolgálónak, hogy frissítse az ügyfél ,A" címre- 
kordját. Ha az ügyfél ezen kívül DHCP ügyfél is, akkor a 
DHCP bérlések kezelésekor a címmel kapcsolatos esemé- 
nyek (például új cím kiadása vagy cím megújítása) bekövet- 
kezésekor a DHCP ügyfél a DHCP kiszolgálónak 81-es DHCP 
opciót küld a teljes nevével együtt. A DHCP kiszolgáló en- 
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nek hatására PTR bejegyzést hajt 
végre az ügyfél nevében. A statiku- 
san beállított Windows 2000 operá- 
ciós rendszerek saját maguk elvégzik 
az A és PTR bejegyzést is. 

Ha egy Windows 2000 DHCP ügyfél 
olyan, alacsonyabb szintű DHCP ki- 
szolgálót szólít meg, amely nem is- 
meri a 81-es opciót, akkor az ügyfél 
saját maga gondoskodik a PTR be- 
jegyzésről. A Windows 2000 DNS ki- 
szolgálót felkészítették a dinamikus 
frissítések kezelésére. 

Azért kell ezt a módszert használni (az ügyfél frissíti az A, a 
DHCP kiszolgáló pedig a PTR bejegyzést), mert csak a munka- 
állomás tudja, hogy a számítógép mely IP címei tartoznak 
egy adott névhez. Mivel a DHCP kiszolgáló hiányosan infor- 
mált, nem tudja hiánytalanul végrehajtani az A erőforrás be- 
jegyzését. Szükség esetén a DHCP kiszolgáló is beállítható 
úgy, hogy mindkét rekordtípus bejegyzését elvégezze. 


A következő részben a DNS működését és az erőforrásrekor- 
dok felépítését elemezzük. 
folytatjuk... 


Fóti Marcell 
marcellfonetacademia.net 
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Személyes adataink védelme 

Az EFS biztosítja azt az alapvető fájltitkosítási 
technológiát, amellyel az NTFS fájlok titkosítva 
tárolhatók a lemezmeghajtón. Az EFS részben 
megoldja azokat az adatvédelmi problémákat, 
amelyeket más operációs rendszerek eszközei 
okoznak, amelyekkel a felhasználók a hozzáfé- 
rési jogok ellenőrzése nélkül férhetnek hozzá az 
NTFS köteten tárolt fájlokhoz. Az EFS-sel az NTFS 
fájlok adatai titkosítva tárolódnak a lemezen. Az EFS 
nyílt kulcsú titkosítási technológiát használ, amely integrált 
rendszerszolgáltatásként fut, így egyszerűen kezelhető, ne- 
hezen feltörhető és a felhasználó számára láthatatlanul mű- 
ködik. Ha a titkosított NTFS fájlhoz olyan felhasználó próbál 
meg hozzáférni, aki privát kulccsal rendelkezik, képes azt 
megnyitni, és úgy dolgozhat vele, mint egy normál doku- 
mentummal. Ha a felhasználó nem rendelkezik privát kulcc- 

sal a fájlhoz, nem is férhet hozzá a dokumentumhoz. 





Az értékes információkat gyakran védelem nélküli fájlokban 
tároljuk a merevlemezen. Az NTFS partíción tárolt informáci- 
ókhoz való hozzáférés korlátozható, ha a Windows 2000 az 
egyetlen futtatható operációs rendszer, és a merevlemez 
meghajtó nem vehető ki a gépből. Ha azonban valaki nagyon 
hozzá akar férni az információhoz, ez nem nehéz, ha fizikai- 
lag hozzá tud férni a számítógéphez vagy a merevlemezhez. 

Az illetéktelen hozzáférés sok esetben problémát jelenthet: 

2 Ellopott laptop - Az őrizetlenül hagyott laptop pillana- 
tok alatt eltűnhet. Mi van akkor, ha a tolvaj nem a szá- 
mítógépet akarja eladni, hanem a merevlemezen tárolt 
értékes információk érdeklik? 

2 Engedély nélküli hozzáférés - Ha az irodai számítógé- 
peket őrizetlenül hagyjuk, bárki bemehet a helyiségbe, 
és információkat lophat el azokról. 

A személyi számítógépek biztonsága általában jól mérhető 

úgy, ha a merevlemezről történő - szokásos - rendszerindí- 

tás helyett megpróbáljuk a gépet idegen operációs rendszer- 
rel, akár flopiról indítani. Amellett, hogy ezzel a módszerrel 
el tudunk kerülni bizonyos (merevlemezhibákból, és hibás 
rendszerindító partícióból eredő) rendszertöltési problémákat, 
sajnos ez egyúttal lehetővé teszi azt is, hogy a számítógépen 
más operációs rendszert indítsunk el. Ez azt jelenti, hogy ha 
valaki fizikailag hozzáfér a rendszerhez, az az NTFS fájlrend- 
szer olvasására képes eszközzel esetleg olyan adatokat is el- 
olvashat a lemezen, melyhez nyilvánvalóan nincs joga. Ha 
végiggondoljuk, mi is történik ilyenkor, kiderül, hogy csodá- 
ról szó sincsen. Az NTFS tárolja ugyan a fájlok hozzáférését 
meghatározó jogosultságlistákat (ACL), ám az ellen nemigen 
tudunk mit tenni, ha az idegen operációs rendszer rá sem he- 
derít e listákra - megkerülheti a hozzáférés-szabályozás be- 

épített biztonsági funkcióit. Hiába no, igaz a régi mondás: a 

halott indián a legjobb indián. A halott (el nem indított) 

Windows 2000 nyilván nem látja el biztonsági funkcióit. Iga- 

zán éles környezetben már csak emiatt is érdemes gondos- 

kodni a számítógépek fizikai biztonságáról (magyarul elzárá- 
sáról) , amely persze egyúttal jelentősen csökkenti a havonta 
eltűnő egerek számát is. A másik lehetséges módszer a BIOS 
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jelszóvédelmének használata - lenne. Ez a lehetőség azon- 
ban szóba sem jöhet ott, ahol egy számítógépet több fel- 
használó használ. De még ha használnák is - a mindenki ál- 
tal ismert jelszó nem nyújt nagy biztonságot. 


E problémára csak az adattitkosítás jelent megoldást. Léte- 

zik néhány olyan termék, amely jelszóból származó kulcsok 

használatával alkalmazásszintű fájltitkosítást tesz lehető- 
vé. E módszerek legtöbbje azonban csak korlátozottan 
használható, mindegyik hiányos valahol: 

"0 Manuális titkosítás és dekódolás minden használat 
alkalmával. A titkosítási szolgáltatás a legtöbb termék- 
ben nem a háttérben történik. A fájlt minden használat 
előtt dekódolni, majd a használat után újra titkosítani 
kell. Ha elfelejtjük a titkosítást, a fájl védelem nélkül 
marad. Mivel a fájl titkosítását (és dekódolását) a fel- 
használó kezdeményezi, ez igen gyakran elmarad. 

b Az ideiglenes- és lapozófájlok használatából eredő 
problémák. Sok alkalmazás (például a Microsoft Word) 
ideiglenes fájlokat hoz létre egy dokumentum szerkesz- 
tésekor. Ezek az ideiglenes fájlok akkor is titkosítás nél- 
kül maradnak a lemezen, ha az eredeti dokumentum tit- 
kosítva van, így egyszerűvé válik az adatok lopása. 

"5 Az alkalmazásszintű titkosítás Windows felhasználói 
módban történik. Ez azt jelenti, hogy a felhasználó tit- 
kosítási kulcsa tárolódhat a lapozófájlban. A lapozófájl 
adatainak felhasználásával igen egyszerűvé válik az egy 
kulccsal titkosított dokumentumokhoz való hozzáférés. 

-0 Gyenge adatvédelem. A kulcsok jelszavakból származnak. 
Egyszerű, könnyen megjegyezhető jelszavak használata 
esetén ez a védelem könnyen feltörhető. 

0 Nincs adat helyreállítás. Sok termék nem biztosít hely- 
reállítási szolgáltatást. Ez még jobban elbátortalanít- 
hatja a felhasználókat, különösen azokat, akik nem 
akarnak egy új jelszót megjegyezni. A jelszóalapú adat- 
helyreállítás használata újabb hozzáférési problémát 
vet fel. Az adattolvajnak csak a jelszóra van szüksége 
ahhoz, hogy helyreállítsa a titkosított fájlokat. 

Az Encrypting File System (EFS) megoldást nyújt a fenti 

problémákra. A továbbiakban az EFS titkosítási technológi- 

áját, a titkosítás integráltságát, a felhasználói tennivalókat 
és az adat helyreállítást elemezzük. 


Az EFS titkosítási technológia 

Az EFS nyílt kulcsú titkosításon alapul, és kihasználja a 
Windows CryptoAPI architektúrájának előnyeit. A fájlok egy 
véletlenszerűen generált kulccsal kerülnek titkosításra, 
amely független a felhasználó nyílt/privát kulcspárjától; így 
a szokásos feltörési módszerek használhatatlanok. 

A fájltitkosítás bármilyen szimmetrikus titkosítási algorit- 
must képes használni. Az EFS első kiadása a DES-t használ- 
ja titkosítási algoritmusként. A következő kiadásokban más 
titkosítási algoritmusok is elérhetőek lesznek. 
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Az EFS távoli fájlkiszolgálókon tárolt fájlok titkosítá- 
sát és dekódolását is lehetővé teszi. Ilyenkor az EFS 
az adatokat csak a lemezen titkosítja. A hálózaton to- 
vábbra is titkosítatlanul közlekednek az adatok. A 
hálózati forgalom titkosítására használjunk SSL vagy 
IPSec protokollt! 


Az EFS szorosan integrált az NTFS-sel. NTFS köteten még az 
ideiglenes fájlok is öröklik a titkosítást, ilyenek létrehozá- 
sakor az eredeti fájl minden tulajdonsága átmásolódik az 
ideiglenes fájlra. Az EFS az operációs rendszer kernelben 
található, és a nem lapozható memóriakészletet használja 
a fájltitkosítási kulcsok tárolására, így azok sohasem kerül- 
nek a lapozófájlba. 





A felhasználó tennivalói 

Az EFS alapértelmezett beállításaival a felhasználók azon- 
nal, rendszergazdai beavatkozás nélkül titkosíthatnak fájlo- 
kat. Ha a felhasználó a fájltitkosításhoz nem rendelkezik 
nyílt kulcspárral, az EFS automatikusan létrehoz neki egyet. 
A fájltitkosítás és -dekódolás fájlonként vagy könyvtáran- 
ként is elvégezhető. A titkosításra kijelölt könyvtárban min- 
den létrehozott fájl (és alkönyvtár) automatikusan titkosí- 
tásra kerül, s minden fájl egyedi titkosítási kulccsal rendel- 
kezik. Ha egy fájlt egy titkosított könyvtárból ugyanazon a 
köteten belül egy titkosítatlanba helyezünk át, a fájl meg- 
tartja eredeti jellemzőit, azaz titkosított marad. A titkosítá- 
si és dekódolási szolgáltatások a Windows Intézőből (Explo- 
rer) érhetők el, míg gyakorlott felhasználók és helyreállítási 
ügynökök parancssori eszközöket is használhatnak. 

Az Explorerben nyissuk meg a titkosítandó fájl vagy mappa 
tulajdonságlapját, majd kattintsunk az Advanced nyomó- 
gombra, és megjelennek a titkosítási és tömörítési lehető- 
ségek. (Egy fájl nem lehet egyszerre tömörített és titkosított!) 


IE 
(Eg Choose the options you want for this File. 
r Archive and Index attributes 


[7 File is ready for archiving 
[7 For fast searching, allow Indexing Service to index this file 





[7 Compress or Encrypt attributes. 
TT compress contents to save disk space 


[7 Engypt contents to secure dataj 
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A fájlt a használat előtt dekódolni kell, ám ezzel nincs te- 
endőnk, a titkosítás és a dekódolás ugyanúgy a lemez 
adatforgalma közben, láthatatlanul megy végbe, mint a ki- 
és betömörítés. Az EFS automatikusan felismeri a titkosí- 
tott fájlokat és megkeresi a felhasználó kulcsát a rendszer 
kulcstárjában. Mivel a kulcstárolás a CryptoAPI-ra épül, a 
felhasználók a kulcsokat biztonságos eszközökön, például 
intelligens kártyákon is tárolhatják. 

Az EFS első kiadása nem támogatja a fájlok osztott használa- 
tát. Ez azt jelenti, hogy hiába van sok felhasználónak jogosult- 
sága egy titkosított fájlra, kizárólag a titkosítást végző sze- 
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mély (no meg a helyreállítási ügynök) képes az megnyitni. Azt 
is mondhatnánk, hogy ,aki kapja, marja", vagyis akinek leg- 
először jut eszébe a fájl titkosítása, azé a fájl a továbbiakban. 
Az EFS architektúra azonban úgy készült, hogy nyílt kulcsok 
használatával a fájlmegosztást bármennyi felhasználó között 
lehetővé tegye. Így elvileg bárki, aki a titkosításban rész vett, 
saját privát kulcsa használatával dekódolhatja a fájlokat. A 
Windows 2000 következő kiadásában a felhasználók egyszerű- 
en hozzáadhatók (és eltávolíthatók) lesznek a titkosított do- 
kumentumokon engedélyezett felhasználók csoportjához. 


Adat helyreállítás 

Az EFS beépítetten támogatja az adat-helyreállítást. A 
Windows 2000 biztonsági infrastruktúra kötelezővé teszi 
adat-helyreállítási kulcsok beállítását. A fájltitkosítás csak 
akkor használható, ha a rendszerhez be van állítva egy 
vagy több helyreállítási kulcs. A helyreállítási kulccsal csak 
a fájl véletlenszerűen generált titkosítási kulcsa válik elér- 
hetővé, az eredeti felhasználó privát kulcsa nem. Ez bizto- 
sítja, hogy a helyreállítási ügynök még véletlenül sem jut- 
hat mások személyes információihoz. 

A helyreállítás olyan vállalati környezetek számára készült, 
amelyekben a vállalatnak szüksége lehet arra, hogy olyan 
adatokat állítson helyre, amelyeket egy azóta kilépett alkal- 
mazott titkosított, és az is fontos, hogy a helyreállítás ak- 
kor is elvégezhető legyen, ha a titkosítási kulcsok elvesznek. 
A helyreállítási házirend a Windows 2000 tartomány tarto- 
mányvezérlőjén állítható be. Ez a házirend a tartomány min- 
den számítógépére vonatkozik. A helyreállítási házirendet a 
tartományi rendszergazdák állíthatják be, vagy a feladatot 
kijelölt adatvédelmi felhasználóknak is kiadhatják. Így job- 
ban és rugalmasabban szabályozható, hogy ki állíthat hely- 
re titkosított adatokat. Az EFS több helyreállítási ügynököt 
is használhat, több helyreállítási kulcsot is beállíthatunk. 
Az EFS otthoni környezetben is alkalmazható. Ha nincs 
Windows tartomány, az EFS automatikusan generál helyre- 
állítási kulcsokat és azokat számítógépkulcsként menti el. 
Az otthoni felhasználók a rendszergazda fiók használatá- 
val, parancssorból állíthatják vissza adataikat. 


Az Encrypting File System használata parancssorból 

A grafikus felület mellett a Windows 2000 parancssori 
eszközt (Cipher.exe) is tartalmaz a leggyakoribb művele- 
tek elvégzéséhez. 

A C:Nadatok könyvtár titkosítása: 


c:NScipher /e adatok 


Command Prompt 











Az összes, ,bla" karaktersort tartalmazó nevű fájl titkosí- 
tása: 


c:VScipher /e /s tblar 
A parancs teljes kapcsolókészlete a következő: 


CIPHER [/I] 


[/F1 


[/EI/D] [/SC[:dir]] 
[/9] [fájlnév [...]] 


[/A] 


"8 /E (Encrypt) A megadott fájlok és könyvtárak titkosí- 
tása. A könyvtárak ilyenkor megjelölődnek, hogy a ké- 
sőbb hozzáadott fájlok is titkosításra kerüljenek. 

"b /D (Derypt) A megadott fájlok és könyvtárak dekódolá- 
sa. A könyvtárak ilyenkor megjelölődnek, hogy a ké- 
sőbb hozzáadott fájlok se kerüljenek titkosításra. 

"2 /S (Subdir) A megadott műveletet az adott könyvtár- 
ban és annak alkönyvtáraiban található fájlokon hajt- 
ja végre. Az alapértelmezett hely az aktuális könyvtár. 

"0 /I (Ignore) A megadott műveletet akkor is folytatja, 
ha közben hiba lép fel. Alapértelmezésben a CIPHER 
hiba esetén leáll. 

"0 /F (Force) A titkosítási műveletet minden kijelölt fáj- 
lon végrehajtja, még azokon is, amelyek már titkosít- 
va vannak. Alapértelmezésben a már titkosított fájlok 
kimaradnak az új titkosítás során. 

"b /O (auiet) Csak a legszükségesebb információkat je- 
leníti meg. 

Paraméterek nélkül a CIPHER az aktuális könyvtár és az ab- 
ban található összes fájl titkosítási állapotát jeleníti meg. 
A fájl minden olvasási művelet során láthatatlanul dekódoló- 
dik, íráskor pedig titkosítódik. Annak megállapításához, 
hogy a fájl titkosítva van-e, a felhasználó a fájl tulajdonsá- 
gai között ellenőrizheti, hogy a titkosítás be van-e kapcsol- 
va. Mivel a titkosítás a háttérben zajlik, a felhasználó ugyan- 
úgy használhatja a fájlt, mint a titkosítás előtt, például 
ugyanúgy megnyithatja és szerkesztheti a Word dokumentu- 
mot vagy Notepad-del a szöveges fájlt. Ha a titkosított fájlt 
más felhasználó próbálja megnyitni, nem férhet ahhoz hoz- 
zá, mivel nem rendelkezik kulccsal a fájl dekódolásához. 

A rendszergazdáknak nem szabad a rendszerkönyvtár fájl- 

jait titkosítani, mivel ezekre szükség van a rendszer indí- 

tásához. A rendszerindítás során a felhasználók kulcsa 
nem hozzáférhető a fájlok dekódolásához. Egy titkosított 
rendszerfájl könnyen használhatatlanná teheti a rend- 
szert. (Halálos hibát okoz sajnos az autoexec.bat titkosítá- 
sa is. A gép többet nem indul el :-( ) A Windows Intéző vé- 
dekezik is ez ellen, mivel nem titkosítja a rendszerfájlo- 

kat. A Windows későbbi kiadásai lehetővé fogják tenni a 

rendszerfájlok titkosítását. 

Az EFS béta változatai lehetővé tették a titkosított fájlok 

továbbítását a gépek között. A COPY parancs korai válto- 

zatainak volt két csodálatos kapcsolója titkosított fájlok 
másolására, azonban a végleges termékben - sajnos- 
sajnos - ezek már nincsenek benn. 

Az Export Encrypted File (titkosított fájl exportálása) és az 

Import Encrypted File (titkosított fájl importálása) lehető- 
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vé tette (volna), hogy akár flopilemezre (tehát FAT fájl- 
rendszerre) is titkosítottan tegyük ki a fáljokat. Ezután ez 
az exportfájlt más fájlrendszerre, vagy akár szalagos meg- 
hajtóra is átmásolható, illetve e-mail mellékletként is el- 
küldhető, ugyanúgy mint egy normál fájl. Hogy használha- 
tó legyen azon a rendszeren, ahová kerül, a fájlt NTFS kö- 
tetre kell importálni, így az titkosítottként jön létre. 


Fájlok egyszerű másolásakor a másolat titkosítatlan 
lesz, ha az a könyvtár, amelybe másolunk, nincs titko- 
sítottként megjelölve. Ez azért van, mert a normál má- 
solási parancs fájlolvasási műveletet használ, amely- 
hez az EFS a háttérben dekódolja a fájlt. Így egy titko- 
sított fájlról titkosítatlan másolatot hozunk létre. 


Könyvtártitkosítás 

Könyvtárakat is megjelölhetünk titkosítottként. A könyvtár 
titkosítottá tétele azt jelenti, hogy a könyvtárban létreho- 
zott minden fájl alap-értelmezetten titkosított, és minden 
létrehozott alkönyvtár alap-értelmezetten titkosítottként 
megjelölt lesz. A könyvtár fájllistája nem titkosított, így a 
fájlok a szokott módon jelennek meg, ha a könyvtárhoz 
megfelelő hozzáféréssel rendelkezünk. 

A könyvtárak titkosítottként történő megjelölése a fájltitko- 
sításhoz hasonló. Kijelöljük a könyvtárat, és a titkosítást vá- 
lasztjuk a Windows Intézőben. Ilyenkor a felhasználó vá- 
laszthat, hogy csak a könyvtárat jelöli meg titkosítottként, 
vagy a könyvtár minden fájlját és alkönyvtárát is titkosítja. 
A könyvtártitkosítás lehetővé teszi, hogy a felhasználók az 
értékes fájlokat egyszerűen a titkosított könyvtárba másolva 
biztosak lehessenek abban, hogy az titkosítottan tárolódik. 


Helyreállítás 

Az EFS helyreállítási házirendje a rendszer átfogó bizton- 
sági házirendjének része (a tartomány biztonsági házirend- 
jének része a Windows tartományban, vagy a helyi biztonsá- 
gi házirend része önálló számítógépek és kiszolgálók eseté- 
ben). Windows 2000 telepítése után az alap-értelmezett 
helyreállítási ügynök a tartomány rendszergazdája. A tar- 
tomány biztonsági házirendjének részeként a tartomány 
minden Windows 2000 vagy Windows NT alapú számítógé- 
pére vonatkozik. Az EFS Policy (EFS házirend) felhasználói 
felület a Domain Policy (Tartományházirend) és a Local Po- 
licy (Helyi házirend) felület integrált része. E felülettel a 
helyreállítási ügynökök helyreállítási kulcsokat generálhat- 
nak, exportálhatnak, importálhatnak és menthetnek el. 

A helyreállítási házirend és a rendszer biztonsági házirend- 
jének integrálása következetesen alkalmazható biztonsági 
modellt hoz létre. A Windows biztonsági alrendszere végzi 
az EFS házirend kezelését, replikációját és tárolását. Így a 
felhasználók a fájltitkosítást olyan rendszeren is elvégez- 
hetik, amely ideiglenesen offline módban van (például egy 
laptopon) , ugyanúgy, mint ahogy a tárolt bizonyítványok- 
kal a tartományi fiókjukra is bejelentkezhetnek. 

Az EFS csak akkor használható, ha tartományszinten (vagy 
helyileg, ha a számítógép nem egy tartomány tagja) be van 
állítva helyreállítási házirend. A helyreállítási házirendet a 
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tartományi rendszergazdák (vagy erre kijelölt alkalmazot- 
tási házirend kezeli a tartomány minden számítógépéhez a 
helyreállítási kulcsokat. 

Ha egy felhasználó elveszíti a privát kulcsát, a kulccsal vé- 
dett fájl visszaállítható a helyreállítási ügynökök saját pri- 
vát helyreállítási kulcsával. 


Az alap értelmezett helyreállítási kulcs adatvédelme 
egy önálló számítógépen 

A helyi rendszergazda első bejelentkezésekor minden önál- 
ló számítógépre telepítődik az alap értelmezett helyreálli- 
tási házirend. Ez a helyi rendszergazdát teszi a számítógép 
alap-értelmezett helyreállítási ügynökévé. 


Ennek megváltoztatása létkérdés, mert sajnos elég 
könnyen idegenek is Administrator-rá válhatnak 
egy ellopott számítógépen a SAM törlésével - s ez- 
zel egy csapásra az összes titkosított fájl helyreál- 
lítási ügynökévé is válnak! 


1. Kattintsunk a Start-ra, kattintsunk a Run-ra, majd az 
Open mezőbe írjuk be, hogy MMC. Kattintsunk az OK-ra. 

2. Kattintsunk a Console-ra, majd az Add/Remove Snap- 
In-re. Kattintsunk az Add-re. 

3. Kattintsunk a Group Policy-re, majd az Add-re. Hagy- 
juk meg az alap-értelmezett Local Computer beállítást, 
majd kattintsunk a Finish-re. Kattintsunk a Close-ra, 
majd az OK-ra. 

4. A Local Computer Policy mellett kattintsunk a --ra. 
Ugyanígy nyissuk ki a Computer Configuration-t, a 
Windows Settings-t, a Security Settings-t, majd a Pub- 
lic Key Policies-t, majd kattintsunk az Encrypted Data 
Recovery Agents-re. A képernyőn az alábbi ábrához ha- 
sonlónak kell megjelennie. 


Ta Console1 - (Console Root Local Computet PolicyiComputer Configuzátű 
In Sonsoda Window Help DD ő ta] m [adoja 
]/áetion Yew Enortes [d 5 [Elmis[DBé ] 
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Enaypted Data Recovery Agents store contains 1 certficate 


A házirendben láthatunk egy Administrator bizonyítványt 
is. Ez a helyi rendszergazdát teszi az alap értelmezett hely- 
reállítási ügynökké. Ha ezt a bizonyítványt letöröljük, üres 
helyreállítási házirendet hozunk létre, amely kikapcsolja az 
EFS-t. Az EFS nem engedélyezi az adattitkosítást, ha nincs 
helyreállítási ügynök. A bizonyítványhoz kapcsolódó hely- 
reállítási kulcs védelméhez... 

1. Kattintsunk a Console-ra, majd kattintsunk az Add/Re- 

move snap-ins-re. Kattintsunk az Add-re. 
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2. Kattintsunk a Certificates-re, majd az Add-re. Kattint- 
sunk a Current User-re, a Finish-re, a Close-ra, majd 
az OK-ra. 

3. A Certificates-Current User mellett kattintsunk a --ra. 
Ugyanígy nyissuk meg a Personal mappát. A bal oldali 
panelen kattintsunk a Certificates-re. 

4. A jobb oldali panelen kattintsunk az Administrator-re 
és menjünk az Intended Purposes-re. Állítsuk be File 
Recovery-re. Exportáljuk a bizonyítványt és a privát 
kulcsot egy .pfx fájlba. 

5. A .pfx fájl létrehozása után töröljük le a bizonyítványt 
és a hozzá tartozó privát kulcsot a Personal store-ból. 
Így a kulcs egyetlen példánya a .pfx fájlban található. 
Ehhez a jobb oldali panelen kattintsunk az Administra- 
tor-re, majd az eszköztárban kattintsunk a piros X-re. 
Egy üzenet figyelmeztet arra, hogy ezután nem tudjuk 
dekódolni az e bizonyítvánnyal titkosított adatokat. A 
folytatáshoz kattintsunk a Yes-re. 

6. Helyezzük el a .pfx fájlt egy széfben vagy zárható szek- 
rényben. Ezt a fájlt csak akkor kell használnunk, ha 
fájlt kell visszaállítanunk. 


Helyreállítási bizonyítvány kérése 

Ha az alap-értelmezett helyreállítási házirend használata 

mellett döntünk, nem kell helyreállítási bizonyítványt kér- 

nünk. Ha azonban a tartományban több helyreállítási ügy- 

nökre van szükség, vagy ha a helyreállítási ügynök jogi 

vagy vállalati okokból nem a tartományi rendszergazda, bi- 

zonyos felhasználókat helyreállítási ügynökké kell tenni, 

és e felhasználók számára fájl-helyreállítási bizonyítványt 

kell adni. 

Ehhez a következőt kell tenni: 

-£ Ha még nincs, létre kell hozni egy Enterprise Certifica- 
te Authority-t (CA). (Erről egy későbbi számban írunk.) 

"0 Az Enterprise CA-nak lehetővé kell tennie a kijelölt fel- 

használóknak vagy ügynököknek, hogy helyreállítási 

bizonyítványt kérjenek és kapjanak. 

Minden kijelölt felhasználónak kérnie kell egy helyre- 

állítási bizonyítványt. 


A kulcsok helye 

Felmerülhet a kérdés, hogy vajon hol tárolja az operációs 

rendszer a felhasználó kulcspárjait. Nos, amíg ki nem ex- 

portáljuk, addig nem a lehető legbiztonságosabb helyen 
vannak - a felhasználó profiljában. Meg is lehet tekinteni 

a kulcspárokat a következő módon: 

1. A Microsoft Management Console (MMC) indításához 
kattintsunk a Start-ra, kattintsunk a Run-ra, az Open 
mezőbe írjuk be, hogy mmc, majd kattintsunk az OK-ra. 

2. A Console menüben kattintsunk az Add/Remove snap- 
ins-re, majd kattintsunk az Add-re. — 

3. Keressük meg a Certificates snap-in-t, majd kattintsunk 
az Add-re. Válasszuk a My user account-ot, és kattint- 
sunk a Finish-re. Kattintsunk a Close-ra, majd az OK-ra. 

4. Keressük meg az Encrypting File System bizonyítványo- 
kat a Personal certificate store-ban. A Certificates-Cur- 
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rent User mellett kattintsunk --ra. Nyissuk meg a Per- 
sonal mappát. Kattintsunk a Certificates-re. 


NMEETILIETEI 
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Már az Intended Purposes mezőben is olvasható, hogy a 
bizonyítvány EFS titkosításra használható. Ha pedig meg is 
nyitjuk, az is láthatóvá válik, hogy itt egy privát kulccsal 
is rendelkező, úgynevezett Digital ID-ről van szó. 
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Certificate Information 


This certificate is intended tos 
"s Altows data on disk to be encrypted 


Issuedto: fm 


Issued by: NetAcademia CA 


Valid fram 10/18/2000 ta 10/18/2001 
hey that corresponds to this certificate, 


Fájlok visszaállítása egy másik számítógépre 
Ha egyes titkosított fájlokat nem csak azon a számítógépen 
akarunk használni, amelyen azok titkosításra kerültek, biz- 
tosítanunk kell, hogy a titkosítási bizonyítvány és a hozzá 
tartozó privát kulcs hozzáférhető legyen a másik rendszeren 
is. Ezt vándorló (központi) profil (Roaming Profile) haszná- 
latával vagy a kulcsok manuális áthelyezésével érhetjük el. 
"8 A Roaming Profile használata. Ha még nincs központi 
profilunk, kérjük meg a rendszergazdát, hogy hozzon 
létre egyet. Ha rendelkezünk központi profillal, az ál- 
talunk használt titkosítási kulcsok minden számítógé- 
pen azonosak, ha ugyanazzal a felhasználói fiókkal je- 
lentkezünk be. Még ha központi profilt használunk is, 
akkor is szükséges lehet a titkosítási bizonyítvány és a 
privát kulcs biztonsági mentése. Ha elveszítjük azokat 
a kulcsokat, amelyek " lehetővé teszik, hogy dekódol- 


telmezésben a 1 Helyi vagy a tartomány rendszergazda) 
helyreállíthatja a titkosított fájlt. 

"0 A tkulcsok manuális áthelyezése. A kulcsok manuális át- 
helyezése előtt készítsünk biztonsági másolatot a titko- 
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sítási bizonyítványról és a privát kulcsról. Így a bizonyít- 
vány és a kulcs egy másik rendszeren is visszaállítható. 


A titkosítási bizonyítvány és a privát kulcs 

biztonsági mentése 

1. Az egér jobb gombjával kattintsunk a bizonyítványunk- 
ra, kattintsunk az All Tasks-ra, majd kattintsunk az 
Export-ra. Ezzel elindítjuk a Certificate Manager Export 
Varázslót. Kattintsunk a Next-re. 

2. Kattintsunk a Yes, export the private key-re. Kattint- 
sunk a Next-re. 

3. A használható exportformátum a Personal Information 
Exchange-PKCSH12, vagy a .pfx (personal exchange for- 
mat). Kattintsunk a Next-re. 

4. A.pfx adatok védelmére adjunk meg jelszót. Kattint- 
sunk a Next-re. 

5. A .pfx adatok tárolásához adjuk meg az elérési útvona- 
lat és a fájlnevet. Esetünkben írjuk be, hogy c:Wmykey. 
Kattintsunk a Next-re. 

6. Az exportálandó bizonyítványok és kulcsok listája jele- 
nik meg. A megerősítéshez kattintsunk a Finish-re. 

7. A Varázsló és a snap-in bezárásához kattintsunk az OK-ra. 

Így a titkosítási bizonyítványt és a privát kulcsot egy 

.pfx fájlba exportáltuk, amelyről biztonsági másolatot 

kell készítenünk. 


A titkosítási bizonyítvány és a privát kulcs 

visszaállítása egy másik rendszerre 

1. Másoljuk a .pfx fájlt egy flopira, és vigyük át arra a szá- 
mítógépre, amelyre a titkosítási bizonyítványt és a pri- 
vát kulcsot importálni akarjuk. 

2. A célszámítógépen is töltsük be az előbb használt MMC 
Certificates snap-int. 

3. A.pfx fájl importálásához az egér jobb gombjával kat- 
tintsunk a Personal store-ra, kattintsunk az All Tasks-ra, 
majd kattintsunk az Import-ra. Így elindítjuk a Certifica- 
te Manager Import Varázslót. A bizonyítvány és a privát 
kulcs importálásához végezzük el a Varázsló lépéseit. " 

4. Adjuk meg a .pfx fájl elérési útvonalát. Példánkban ez 
c:Wnykey.pfx. 

5. A. .pfx adatok kicsomagolásához adjuk meg a jelszót. 

6. Kattintsunk a Place all certificates in the following 
store-ra, majd fogadjuk el a Personal certificate store- 
t. Kattintsunk a Next-re. 

7. Az importálás elindításához kattintsunk a Finish-re, 
majd az OK-ra. Az importálás befejezése után a Varázs- 
ló bezárásához kattintsunk az OK-ra. 

Ezután rendelkezünk az ahhoz szükséges kulcsokkal, hogy 

a titkosított fájlokat ugyanúgy használhassuk, mint azon a 

számítógépen, amelyen a biztonsági mentés történt. 


Mappák és fájlok távoli kiszolgálón 

Távoli kiszolgálókon tárolt fájlokat is titkosíthatunk és de- 
kódolhatunk, valamint használhatjuk is a titkosított fájlo- 
kat. Ez távoli hozzáféréssel is lehetséges, és úgy is, ha a 
másik számítógépre helyileg lépünk be. Ne feledjük azon- 
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ban, hogy ha a titkosított fájlokat a biztonsági mentéssel 
és visszaállítással helyezzük át, a megfelelő titkosítási bi- 
zonyítványt és a privát kulcsokat is át kell helyeznünk ah- 
hoz, hogy a titkosított fájlokat az új helyen is használhas- 
suk. Megfelelő privát kulcsok nélkül nem nyithatjuk meg 
vagy dekódolhatjuk a fájlokat. 


Az EFS felépítése 

Titkosítás 

Az EFS az adattitkosítást és -dekódolást az eddig taglaltak- 
nak NEM megfelelően, a közhiedelemmel ellentétben nem 
nyílt kulcsú algoritmussal végzi. Ennek több oka is van, az 
egyik ezek közül a teljesítmény: a szimmetrikus titkosítási al- 
goritmusok (például a DES) egy nagyságrenddel gyorsabbak, 
mint a kulcspárral működők. A másik ok pedig a fájl többfel- 
használóssá tétele. A nyílt kulcsú kulcspárral NEM a fájl tar- 
talmát titkosítjuk, hanem azt a DES kulcsot, ami a fájl egye- 
di titkosító kulcsa. Ezt úgy lehet elképzelni, mintha minden 
jogosult felhasználó, valamint a helyreállítási ügynök rendel- 
kezne a KULCSDOBOZ KULCSÁVAL. Privát kulcsával nem ma- 
gát a fájlt nyitja, hanem a fájl kulcsát rejtő ládikát. 

A fájlok egy véletlenszerűen generált fájltitkosítási kulcs (file 
encryption key, FEK) használatával kerülnek titkosításra, amely 
független a felhasználó . nyilvános Vagy privát kulcspárjától; 
Ezután a FEK külön (egy vagy több kulcstitkosítási nyílt kálcs 
használatával) titkosításra kerül, így létrejön a titkosított 
FEK-ek listája. A FEK titkosítása a felhasználók kulcspárjá- 
nak nyílt részével történik. A titkosított FEK-ek listája ez- 
zel a titkosított fájllal együtt tárolódik a speciális adatde- 
kódolási mező (Data Decryption Field, DDF) nevű EFS attri- 
bútumban. A fájltitkosítási információ szorosan kapcsoló- 
dik a fájlhoz. A dekódoláshoz a felhasználók kulcspárjának 
privát része kerül felhasználásra. A FEK dekódolásához szin- 
tén a kulcspár privát része kell. A felhasználók kulcspárjá- 
nak privát részét máshol kell biztonságosan tárolni - intel- 
ligens kártyákon vagy egyéb biztonságos tárolóeszközökön. 





Elvileg a FEK titkosítható lenne szimmetrikus algo- 
ritmussal, például jelszóból származó kulccsal is. Az 
EFS ezt nem támogatja, mivel a jelszó alapú sémák 
mindenképpen gyenge védelmet nyújtanak a feltöré- 
si kísérletekkel szemben. 


A titkosított helyreállítási FEK-k e listája szintén a fájllal 
együtt tárolódik az adat-helyreállítási mező (Data Recove- 
ry Field, DRF) nevű speciális EFS attribútumban. A DRF-ben 
csak a helyreállítási kulcspárok nyílt részére van szükség a 
FEK titkosításához. A normális fájlrendszerműveletekhez 
ezeknek a nyílt helyreállítási kulcsoknak mindig megtalál- 
hatóknak kell lenniük az EFS rendszerben. A helyreállítás 
ritkán végzett művelet, amelyre csak akkor van szükség, ha 
egy felhasználó kilép a vállalattól vagy elveszíti a kulcsát. 
A helyreállítási ügynökök ezért a kulcsok privát részét más- 
hol (intelligens kártyán vagy más biztonságos tárolóeszkö- 
zön) is tárolhatják. 
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A következő ábrák a titkosítási, a dekódolási és a helyre- 
állítási folyamatot mutatják be. 


A guick brown 
fox jumped 


Private 0 sé 


File Encryption 
(0129) 





Data Decryption 


Field cikníááá szí 





Data 


Field generation Recovery 
ts 


Data Recovery 
át 





A fenti ábra a titkosítási folyamatot mutatja be. A fájl egy 
véletlenszerűen generált FEK használatával kerül titkosí- 
tásra. Ez a fájltitkosítási kulcs (FEK) a fájllal együtt táro- 
lódik a felhasználó nyílt kulcsával titkosítva a DDF-ben és 
a helyreállítási ügynök nyílt kulcsával titkosítva a DRF- 
ben. Ez az ábra csak egy felhasználót és egy helyreállítási 
ügynököt jelenít meg — a valóságban több, független kulcs- 
csal rendelkező felhasználó és helyreállítási ügynök is le- 
het (bár az EFS első kiadása csak egy felhasználót támo- 
gat). Az alábbi ábra a dekódolási folyamatot mutatja be: 
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Data Decryption 
Field Extraction 
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A FEK a felhasználó privát kulcsával és a DDF titkosított 
FEK elemének használatával dekódolódik. A FEK haszná- 
latával a fájl adatai blokkonként dekódolódnak. Nagy fájl 
esetén csak adott blokkok dekódolására van szükség, 
nem kell az egész fájlt dekódolni. 


Users 
ey 


Key 


Felhívom kedves olvasóim figyelmét, hogy e havi Dupla KV 
rovatunkban egy, az EFS-hez kapcsolódó ügyes trükkről 
esik szó, melynek segítségével Encrypt/Decrypt menüpon- 
tot varázsolhatunk a fájlok gyorsmenüjébe! 


Fóti Marcell 
marcellfonetacademia.net 
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Biztonságos levelezés Microsoft Exchange 5.5 és 
Exchange 2000 segítségével 
Az elektronikus levelezés nemcsak mennyiségé- 
ben nőtt az utóbbi években, hanem tartalmá- 
ban is változik. A multinacionális, és több te- 
lephellyel rendelkező cégek, valamint az Inter- 
neten folytatott kereskedelem térnyerésével az 
elektronikus levelek egyre nagyobb hányada tar- 
talmaz bizalmas üzleti információkat, ellentét- 
ben az Internetes hőskorban leginkább elterjedt 
baráti levelezéssel. 

Mindezek következtében az elektronikus levelezés biztonsá- 

ga egyre fontosabbá válik. Gondoljunk csak a nemrégiben a 
,szerelemvírus" által okozott közvetett és közvetlen károkra, 
láthatjuk, hogy már ma is mennyire függenek a cégek az 
elektronikus levelezéstől. 
Ebben a cikkben áttekintést adunk az elektronikus levele- 
zés biztonsági kérdéseiről és a biztonság növelésének le- 
hetőségeiről Microsoft Exchange Server 5.5 és Exchange 
2000 Server környezetben. 





Mi ellen védekezzünk? 

Nézzük meg, hogy milyen veszélyek is leselkednek egy leve- 
lezőrendszerre? 

A legnyilvánvalóbb veszély, hogy az elektronikus levelekhez 
illetéktelenek férnek hozzá. Ezek az , illetéktelenek" lehetnek 
cégünkön belül (ez a gyakoribb!) , vagy az Interneten. A hoz- 
záférés lehet csak a levél elolvasása, vagy a levél módosítása. 
A második fő veszélyforrás az, ha valaki úgy küld valakinek 
levelet, mintha azt mi küldtük volna, azaz csal. 

A harmadik problémakör, hogy a levelezőrendszerünket olyan 
nagy terhelésnek teszik ki, ami a ,hasznos" terhelés kárára 
megy. Ennek szélsőséges esete az, hogy a levelező kiszol- 
gálónkat, vagy annak bizonyos komponenseit teljesen ,leha- 
lasztják" (Denial of Service, DoS támadás). 

A negyedik nemkívánatos jelenség a vírusok és trójai falovak 
bejuttatása e-mailen keresztül. Ezek aztán a legkülönfélébb 
károkat tudják okozni (munkaállomások tönkretétele, vagy 
az előbb említett DoS támadás a levelező kiszolgáló ellen, 
immár a saját hálózatunkról) . 

Az utolsó, de legáltalánosabb dolog amire fel kell készül- 
nünk, a rendszerünk bármilyen okból történő meghibásodá- 
sa. Ez ellen nem tudunk tökéletes védelmet kialakítani, hi- 
szen ,ami elromolhat az el is romlik", úgyhogy a leghi- 
batűrőbb, legdrágább rendszer esetében is fel kell készül- 
nünk a rendszerünk újraépítésére, ami lehet akár csak a le- 
véladatbázis visszaállítása, de akár lehet komplett levelező- 
rendszerünk új hardverre történő újratelepítése is. 


Helyezzük biztonságba a kiszolgálót 

A legfontosabb a védekezési stratégia kialakításában, hogy 
magát a levelező kiszolgálónkat biztonságossá, illetéktelenek 
számára hozzáférhetetlenné tegyük. Ez egyrészt azt jelenti, 
hogy a kiszolgálónk biztonságos módon legyen elhelyezve, 
például legyen zárva az a helyiség, ahol tartjuk. A hálózatot 
nem tudjuk elzárni, legalábbis a belső felhasználók elől nem, 
de a hálózat biztonságát fokozhatjuk. Ezeken kívül az operá- 
ciós rendszert és a levelező kiszolgálót olyan beállításokkal 
lássuk el, ami a lehető legnagyobb biztonságot nyújtja. 
Most itt következhetne egy általános ismertetés a hálóza- 
tok és a Microsoft Windows NT 4.0 és Windows 2000 biz- 
tonsági lehetőségeiről, de ez nem tárgya ennek a cikknek. 
Csak pár ,hívószó" álljon itt: 


levelezés 1. rész 


hub helyett használjunk kapcsolót, 

használjunk tűzfalat, de legalább két hálókártyás kiszolgálót, 
a hálózati kártyákról szedjük le a nem használatos szol- 
gáltatásokat, 

használjunk NTFS fájlrendszert FAT helyett, 

vigyázzunk az , everyone full controll" jellegű alapbeállí- 
tásokra mind a megosztásoknál, mind az erőforrás-hoz- 
záféréseknél! 
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Telepítsünk biztonságosra 

A cikk következő részeiben az egyszerűség kedvéért feltéte- 
lezzük, hogy az Exchange 5.5-öt Windows NT 4.0-án használ- 
juk, míg az Exchange 2000-et természetesen Windows 2000 
Advanced Serveren futtatjuk Active Directory-val a háttérben. 
Az Exchange kiszolgálónk telepítésére is érvényes az előbb em- 
lített általános tanácsok közül jó néhány. Az Exchange 5.5 ese- 
tében az telepítésnél csak azokat a szolgáltatásokat rakjuk fel, 
amit ténylegesen használunk. Először is ne használjuk , Typical" 
meg a ,Minimal" lehetőséget a telepítésnél, mivel úgysem je- 
gyezzük meg fejből, hogy például a Microsoft által tipikusnak 
vélt komponensek mik is. Ezért a , Complete/Custom" lehetőség 
irányába haladjunk. Ez is egy kicsit , becsapós", mert a választ- 
ható komponensek az , Exchange Server" , mögött" vannak el- 
rejtve, a , Change Option..." gomb megnyomása után megjele- 
nő dialógusablakban választhatók ki, így gyakran ottfelejthet- 
jük például a biztonsági veszélyt rejtő MSMail Connectort, vagy 
épen a biztonságot szolgáló Key Manager Server marad ki, mert 
az alapértelmezésben például nincs kiválasztva. 






Inthe Opbonz lt, select emma you want inatalad: eds tom: you dó nol want inatallod. 
I you want to iratal oriy part ol tha selected option, ehooza Change Üpőon. 
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Az exchange 5.5 telepítő alapbeállításai 


A következő biztonsági szempontból kritikus lépés az amúgy 
egyszerű folyamatban a szolgáltatás által használt felhaszná- 
lói fiók, azaz , service account" kiválasztása. A telepítő pár- 
beszédpanelje alaphelyzetben azt a fiókot ajánlja fel, akinek 
a nevében a telepítés éppen folyik. Ezt általában nem jó vá- 
lasztani több okból sem. Egyrészt a telepítést végző sze- 
méllyel ellentétben a szolgáltatás-fióknak nem kell rendszer- 
gazdának lennie, azaz sérül a , szükséges minimális jogkörök 
kiosztása" szabály, másrészt, ha figyelmetlenségből a külö- 
nösen védendő adminisztrátori fiók jelszavát úgy változtat- 
juk meg, hogy ezt nem jelezzük az Exchange számára, akkor 
a kiszolgáló egy esetleges újraindulásnál nem fog rajta az Ex- 
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change elindulni. Azaz a telepítés előtt hozzunk létre egy 
külön felhasználói fiókot, jó nehezen kitalálható jelszóval, 
amit csak az Exchange szolgáltatás futtatására használunk, 
és ezt válasszuk ki a telepítéskor. 

Ennek a fióknak alaphelyzetben nem kell semmi különös jo- 
got adni, illetve nem kell semmilyen speciális csoportba 
tenni, csak az alaphelyzet szerinti , Domain Users" csoport- 
ban kell bennhagyni, a szükséges egyéb jogokat a telepítő 
automatikusan megadja. Néhány egyéb komponens, mint 
például egyes vírusvédelmi megoldások, vagy a korábban 
említett Key Management Server azonban egyéb igényeket 
is támaszthatnak, ezt természetesen vegyük figyelembe. 
Ilyenek lehetnek bizonyos könyvtárak olvasásának joga, lo- 
kális bejelentkezési jog, esetleg helyi adminisztrátori jog. 
Az Exchange 2000 telepítése ilyen szempontból egyértel- 
műbb, a komponensek a telepítő-varázsló megfelelő lapján 
kiválaszthatók. A szolgáltatási fiók pedig maga a System 
Account, hiszen a Windows 2000-ben már ez a fiók is alkal- 
mas hálózaton keresztül más gépeken szolgáltatások igény- 
bevételére, ami az Exchange esetében például az Active Di- 
rectory eléréséhez kell. Ez a fiók biztonságosabb, mint bár- 
milyen más, általunk felvett felhasználói fiók, hiszen ennek 
a jelszavát csak a gép tudja, és a Windows 2000 automati- 
kusan változtatja 7 naponként. 

A telepítés utolsó lépéseként tegyük föl az aktuális javító- 
csomagokat, ami jelenleg az Exchange 5.5-nél az SP3 (4-es 
hamarosan megjelenik) , az Exchange 2000-nél még nincsen, 
de már készül. A javítócsomagok nemcsak szigorúan vett ja- 
vításokat tartalmaznak, hanem éppen a biztonsági lehetősé- 
gek terén újabb funkciókat is adnak. 


Telepítés utáni első teendők 

A telepítés után a , friss" Exchange-nél van néhány olyan 
biztonsági hiányosság, amit rossz szándékú emberek kihasz- 
nálhatnak, ezért érdemes ezeket először befoltozni, mert ha 
már lehetővé tesszük az emberek számára, hogy bejelent- 
kezzenek az Exchange rendszerbe, akkor már lehet, hogy ké- 
ső, és néhányan , szórakozásból" tönkretehetik azt. 
Mindkét Exchange verzió esetében telepítés után szabad a 
vásár a nyilvános mappák létrehozására és ezekbe korlátla- 
nul tölthetnek fel dokumentumokat tetszőleges méretben. 
Ugyanilyen szabadsággal rendelkeznek a saját levelesládáik- 
ban is. Mindezekkel rövid idő alatt annyi dokumentumot 
tölthetnek a kiszolgálóra, hogy az , meghal". 

Amennyiben használjuk a levelek nyomkövetése (Message 
Tracking) funkciót, akkor a nyomkövetési információkat tar- 
talmazó mappának (Exchange 5.5: Tracking.log, Exchange 
2000 esetében szervernév.log) megosztási jogaira legyünk fi- 
gyelemmel, hiszen alaphelyzetben ez a mappa mindenki 
számára olvasható a hálózaton keresztül, így akár bizalmas 
levelekről is kinyerhetnek fontos információkat. 


Jogosultságok 

A legtöbb biztonsági rést azáltal tehetjük a rendszerünkbe, 
ha nem megfelelően állítjuk be a jogosultságokat. Ugye gya- 
kori eset, hogy a levelező kiszolgálónkat nemcsak egy ember- 
nek kellene rendszer-felügyelni, hanem több rendszergazdát 
szeretnénk különböző szereppel felruházni. Itt mindig ügyel- 
jünk a , minimális szükséges jog" kiadásának szabályára. 

Az Exchange 5.5 rendszernél kicsit hibrid a megoldásunk, 
hiszen külön van az NT biztonsági rendszere és adatbázisa 
(SAM), és az Exchange 5.5 címtára (Directory). A kettő kö- 
zötti kapcsolatot az NT felhasználói fiókok részére az Ex- 








change címtár objektumaira kiadott jogosultságok jelentik. 
A jogok kiosztásának megkönnyítésére az Exchange 5.5 sze- 
repeket definiál, amelyek beállításával egy előre elkészített 
jogosultsághalmazt tudunk egy mozdulattal beállítani. 
Bővebben itt nem kívánunk kitérni a jogosultságok és sze- 
repek rejtelmeire, de annyit biztonság szempontjából fontos 
megjegyezni, hogy ha az Exchange 5.5 címtárból minden 
olyan felhasználót leszedünk, akinek van joga a jogosultsá- 
gokat átállítani (Permissions Admin) , akkor címtárunk meg- 
lepő módon éppen védtelen lesz. Azaz annak érdekében, 
len legyen, inkább azt választották a fejlesztők, hogy ilyen 
esetben inkább legyen szabad a gazda, azaz bárki, aki eléri 
az Exchange 5.5 Servert tudja azt konfigurálni :-O 
Exchange 5.5 szerepek és jogok 






General Permissions ] 
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Modily User Áttibutes 
Modily Admin Attibutes 





Az Exchange 5.5 esetében az is nehézkessé teszi a bizton- 
ságos jogosultsági rendszer kiépítését, hogy az Exchange 
üzenet-adatbázisaiban (Mailbox Store és Public S-ore) és bi- 
zonyos korlátozásoknál már nem NT fiókoknak osztunk ki és 
veszünk el jogokat, hanem az Exchange címtárban definiált 
postaládáknak és csoportoknak (Distribution Lists). 

Az Exchange 2000 esetében az Active Directory integráció 
miatt itt egyben, az NTFS jogosultsági rendszeréhez teljesen 
hasonló módon kezelhetjük a jogosultságokat, azaz akinek 
megfelelő joga van az Active Directory Exchange objektuma- 
ihoz hozzáférni, akkor az tudja konfigurálni az Exchange 
rendszerünket. Ezen még az is újdonság az 5.5-höz képest, 
hogy az objektumhierarchia magasabb szintjén kiadott jo- 
gokat alsóbb szinten korlátozni tudjuk, ezzel sokkal hatéko- 
nyabban és finomabban tudjuk azokat kiadni. 


Exchange 2000 jogok az Exchange System Managerben 
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Remove 








CÍ Authenticated Users 

22 Domain Admins (WSHADomain Admins) 

Í Enterprise Admins (WSHYEnteiprise Admins) 

Everyone 

lelsz KT] 

Permissions: Allow  Deny 
Modily public folder replica list EB OO 
Open mai send gueue HB OO 
Read metabase properties a 
Administer information store EB a 
Create named properties ín the information store E a Hi 
View information store status E a :] 





Természetesen bizonyos műveletekhez szükséges magán az 
Exchange szolgáltatásokat futtató gépen is hozzáféréssel 
rendelkeznie a rendszergazdának, de például postaládát tud 
létrehozni egy olyan , Domain Admin" rendszergazda is, aki- 
nek az Exchange 2000 rendszerben csak , View Only" szere- 
pe van. Azaz az Exchange 2000 esetében ügyelni kell arra, 
hogy bizonyos funkciók feletti ellenőrzés kikerült az Exchan- 
ge Server felügyelete alól és az Active Directory-hoz került. 
Az Exchange rendszerben jogosultságokat egy ú.n. , Delega- 
tion Wizard" segítségével tudunk legegyszerűbben kioszta- 
ni, de természetesen módunk van arra is, hogy minden 
egyes objektumra a varázsló nélkül osszunk ki jogokat. 


Hálózati és tartalom-titkosítás, elektronikus aláírás 
Eddig azzal foglalkoztunk, hogy magát a levelező kiszolgá- 
lónkat megvédjük, de mi van magukkal a levelekkel, amik el- 
hagyják a kiszolgálót és a belső hálózaton, vagy az interne- 
ten elkezdenek vándorolni? 

A belső hálózatunkban viszonylag biztonságos a levelek 
vándorlása Exchange Server és Outlook között abból a szem- 
pontból, hogy ha valaki figyeli a hálózatunkat, akkor nem 
fogja a levelek tartalmát egy az egyben látni, mert az RPC 
alapú kommunikáció eleve nem ,.clear text", de nem vissza- 
fejthetetlen! Ha ennél biztosabbat akarunk, akkor használ- 
hatjuk az Outlookban az RPC kommunikáció titkosítását; a 
régebbi verzióknál 40 bites titkosításunk volt, az Outlook 
2000 SR1-nél már 128 bites titkosításra van lehetőségünk. 
Az előbb említett védelem csak arra az időre védi a levelün- 
ket, amíg a hálózaton utazik. Mi van, ha illetéktelen helyre 
érkezik? Ott minden további nélkül ismét olvashatóvá válik. 
Ez úgy képzelhető el, hogy a fürkésztekintetű rendszergaz- 
dánk , véletlenül" jogot oszt ki a mi postafiókunkra magának 
és ezek után gond nélkül nézegeti a levelezésünket. 
Hasonló problémánk lehet az internetes levelezéskor, azzal 
kiegészítve, hogy alaphelyzetben a levélküldés protokollja 
(SMTP) és az internetes kliensek (pl.: Outlook Express) levél- 
letöltő protokollja (POP3, IMAP4) is olvasható szöveges for- 
mátumban továbbítja a leveleket, azaz mind a hálózati for- 
galmat figyelők, mind az esetlegesen levelünket továbbító 
kiszolgálókhoz hozzáférők olvashatják a levelezésünket. 
Ezen problémák kiküszöbölésében segít a levél titkosítása, 
melynek során különböző titkosítási kulcsokkal olvashatat- 
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lanná tesszük azt. 

Az internetes levelezés esetén is van mód magának a kom- 
munikációnak a titkosítására, azaz hogy nemcsak a levelet 
titkosítjuk, hanem magát azt a protokollt is, amelyen keresz- 
tül a levél eljut egyik helyről a másikra. Ezt a Secure Socets 
Layer és a Transport Layer Security protokollok szolgálják, 
amelyek a felsőbb szintű protokollok (pl.: IMAP, http, SMTP, 
POP) alatt képeznek titkos csatornát. Hasonló célt szolgál a 
Virual Private Network kialakítása is (PPTP vagy L2TP). 
Amellett, hogy garantálni kell, hogy levelünket tényleg csak 
a címzett tudja elolvasni, őt is meg kell nyugtatni, hogy azt 
a nagyon titkos levelet tényleg mi küldtük, méghozzá úgy, 
hogy abba útközben nem írt bele senki. Ez nem feltétlenül 
ugyanaz, mint titkosítani valamit, hiszen lehet, hogy nem 
bánom, hogyha a levelemet bárki elolvassa, csak az a fon- 
tos számomra, hogy aki elolvassa az egyértelműen meg tud- 
jon győződni arról, hogy azt tényleg én írtam. Erre való az 
elektronikus aláírás. 


Titkosítás kulcsokkal, bizonyítványokkal 

Hogyan tudjuk elérni mindazt, amit az előzőekben leírtam? 
Okos emberek kitaláltak különböző matematikai algoritmu- 
sokat arra, hogy hogyan lehet speciális számokkal (kulcsok- 
kal) az adatokat jelentő másik számokat úgy megváltoztat- 
ni, hogy a visszafejtéshez csak az eredeti kulcs, vagy egy bi- 
zonyos másik kulcs alkalmas, azaz csak úgy kitalálni nem le- 
het a kódoló kulcsot, csak próbálgatással. Ha a kulcs elég 
nagy lehet, akkor kitalálni azt olyan sok próbálgatással jár, 
amit a jelenlegi technikákkal nagyon sok időbe telne, akár 
több száz évbe is. Gondoljunk egy olyan aktatáska kinyitá- 
sára, amelyen nem 4 számjegy a számzár, hanem pl. 100! 
A titkosításra két fő módszer van. Az egyik az, hogy a címzett 
és a feladó megegyezik egy közös kulcsban, amivel a feladó 
titkosítja a levelet, majd ugyanezzel a kulccsal a címzett 
visszafejti. A másik módszer a kétkulcsú vagy más szóval nyil- 
vános kulcsú titkosítás, amelyben az adatot a feladó a cím- 
zett nyilvános, vagy más szóval titkosító kulcsával titkosítja, 
elküldi, és ezt csak a nyilvános kulcs privát párjával rendelke- 
ző címzett tudja visszafejteni. Az első előnye, hogy a rendel- 
kezésünkre álló algoritmusok nagyon gyorsak, azaz nagy 
mennyiségű adatot, vagy akár adatfolyamokat is lehet vele 
titkosítani. A második előnye, hogy nem kell azzal törődni, 
hogy vajon azt az egy kulcsot, ami az egykulcsú titkosításnál 
van, vajon hogyan juttatjuk el biztonságos módon a feladó- 
nak, hanem mivel itt kulcspárok vannak, az egyik felét, a nyil- 
vános kulcsot bárkinek, bármilyen módon elküldhetjük. 

De vajon mi biztosítja, hogy ha én Vegetári János kollégám- 
nak akarok egy titkos levelet küldeni, és megkérem, hogy 
küldje el a titkosításra használt nyilvános kulcsát (és kapok 
is egy kulcsot), hogy az tényleg tőle van? Hiszen ezt a ké- 
rést, amíg nem tudok vele titkosan levelezni, bárki elcsíphe- 
ti, és gyorsan elküldi a saját kulcsát. Az ilyen jellegű prob- 
lémákra találták ki a bizonyítványt kiadó hatóságokat (Cer- 
tificate Authority). Ezek akár olyan ténylegesen működő 
szervezetek is lehetnek, akik számára valamilyen módszerrel 
hitelesítem magam, amit ők elismernek, és az én nyilvános 
kulcsomat hajlandóak minősíteni, hogy az tényleg az enyém. 
Ha Vegetári János kollégámtól kapok egy bizonyítvánnyal 
ellátott kulcsot, akkor megbizonyosodhatok arról, hogy ez 
tényleg az övé, például úgy, hogy lekérem az interneten ke- 
resztül a hitelesítő cégtől, hogy az ilyen és ilyen sorszámú 
bizonyítvány tényleg hiteles-e. 


Mit tudunk mindezekkel a technológiákkal kezdeni? 





Microsoft. 
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6€ Titkosítás. Generálunk egy titkos kulcsot, és egykulcsú 
titkosítással titkosítjuk a levelet, majd a végére 
biggyesztjük a címzett nyilvános kulcsával titkosított 
titkos kulcsot. Ennek az az egyik előnye, hogy gyors (a 
nagy adattömeg egykulcsú titkosítással van kódolva), és 
mégis titkosan megy át a címzetthez a titkosító kulcs. 
Másrészt, ha több címzettem van, akkor nem az egész 
üzenetet kell minden egyes címzett nyilvános kulcsával 
kódolni, hanem csak a titkosító kulcsot, ami általában 
jóval kisebb adattömeget jelent, mint maga a levél. A 
címzett(ek) a privát kulcsá(ai)val kibontja(ák) a titko- 
sító kulcsot, és azzal dekódolja(ák) a levelet. 

6 Elektronikus aláírás. Készítek egy hash-t (hash - az 
adatból létrehozott, annál jóval kisebb szám, amiből nem 
lehet visszafejteni az eredeti adatot, és ha az adat akár 
csak 1 számjegyét is megváltoztatom, akkor a hozzá tar- 
tozó hash lényegesen megváltozik) a levélből, és azt kó- 
dolom a privát kulcsommal, és ezt a kódolt hash-t, a 
nyilvános kulcsomat és annak bizonyítványát a levél 
mellé rakom. Ezzel maga a levél olvasható marad (átlát- 
szó aláírás), de a címzett tudja ellenőrizni a mellékelt 
bizonyítványt, és meg tud győződni, hogy a levelet 
tényleg én küldtem. Sőt, ha ő is elvégzi a hash képzést, 
és összehasonlítja azzal, amit én kódolt formában a le- 
vélhez raktam, akkor el tudja dönteni, hogy a levelet út- 
közben módosították-e. Ha módosították volna, akkor 
eltérne egymástól a két hash. (Csinálhatunk ú.n. nem 
átlátszó aláírást is, ami az egész üzenetet beteszi magá- 
ba az aláírásba, bináris formában, hogy ha a levél külön- 
böző levelező kiszolgálókon megy át, nehogy azok vélet- 
lenül megváltoztassák, pl. a szöveges részt áttördeljék, 
ezzel megsértve a levél módosítatlanságát. ) 

Térjünk csak vissza egy pillanatra a bizonyítványok kiadásá- 

ra! Honnan tudom, hogy egy bizonyítványt tényleg az a 

szervezet küldte, akitől én kértem? Hát onnan, hogy a bizo- 

nyítványt a kiállító szervezet is aláírja elektronikusan. Sőt, 
miért higgyek én mindenféle kis hitelesítő szervezet aláírá- 
sában? Általában a hitelesítő szervezet aláírásában benne 
van az is, hogy őt milyen felettes hitelesítő szervezet minő- 
sítette. Ha bizalmatlan vagyok, végig tudom ellenőrizni az 
egész minősítési hierarchiát. A tetején sajnos lesz egy olyan 

CA, amit muszáj elfogadnom hitelesnek, mert azt már nem 

fogja senki hitelesíteni, csak saját maga. 


Certificate Server és Key Management Server 

Az Exchange 4.0 verziójától kezdődően a telepítő CD-n meg- 
található az emelt szintű biztonságot megvalósító opcioná- 
lis komponens, a Key Management Server (KMS). Ez teszi az 
Outlook kliensprogram felhasználásával, lehetővé teszi hogy 
a felhasználók elektronikusan titkosított és/vagy aláírt leve- 
leket küldjenek egymásnak. A KMS két kulcspárt, egy aláíró 
és egy titkosító kulcspárt kezel a felhasználóknak, és egy 
külön adatbázisban tárolja annak érdekében, hogy ha a fel- 
használók elveszítik a privát kulcsaikat, akkor vissza lehes- 
sen állítani azokat ebből az adatbázisból. Az Exchange 5.5 
SP1 óta ezeket a kulcsokat olyan bizonyítvánnyal láthatjuk 
el, amelyek megfelelnek a Secure MIME előírásoknak, így 
szabványosak, tehát a nem Exchange és nem Outlook fel- 
használóknak is tudunk ezzel titkosított és aláírt leveleket 
küldeni. Az ehhez szükséges bizonyítványokat nem maga a 
KMS állítja elő, hanem szükséges egy saját Certificate 
Servert is igénybe venni ebből a célból (NT 4-ben az Option 
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Pack-ben van, a Windows 2000-ben már , gyárilag") . 

A KMS használatához tehát először szükségünk van egy Cer- 
tificate Serverre. Ez az Exchange 5.5 esetében egy dedikált 
Certificate Server lesz, mivel rá kell installálnunk egy olyan 
speciális biztonsági modult, ami alkalmassá teszi arra, hogy 
megértse a KMS bizonyítvány-igénylését, és ezzel a , normál" 
felhasználói bizonyítványkérésekre alkalmatlanná tesszük. Az 
Exchange 2000 esetében már nem kell ilyen durva beavatko- 
zást véghezvinnünk a Certificate Serveren, hiszen ez már 
alaphelyzetben megérti a KMS kéréseit. Amiről gondoskodni 
kell viszont Exchange 2000 esetében, az a Certificate Server 
Active Directory integrációja, azaz ú.n. Enterprise CA-t kell 
létrehoznunk. Erre azért van szükség, mert a bizonyítványo- 
kat és az egyes felhasználók titkosítási képességét a KMS az 
Active Directory-ban fogja tárolni, illetve Active Directory 
objektumok, az Exchange Servert futtató gépek fognak bizo- 
nyítványokat igényelni a felhasználók részére. Ha elkészítet- 
tük és felkonfiguráltuk a KMS komponensünket, akkor már 
csak a felhasználóinkat kell bevonni az emelt szintű bizton- 
ság lehetőségébe. (Ez azért nem ilyen egyszerű, de ezt inkább 
gyakorlatban kellene megmutatni.) 

Outlook kliens az emelt szintű biztonsági lehetőséggel 
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Options 


Preferences [ Mail Services ] Máll Format ] spelling " Séaríty [orer ]/ Dlegatss [7 


Searíty zones allow you to asstomtze whether seripts and acta 
content can be run ín HTML messages. Select the Microsoft 


Internet Explorer security zone tő use. 


Ze: eszem ES meal 











A cikk következő részében az Outlook Web Access, az 
internetes kliens protokollok, az SMTP relay lehető- 
ség, kerül terítékre a mentés helyreállítás problémái- 
ról, vírusvédelem lehetőségeiről és az Outlook 2000 
SR1 biztonsági újdonságairól is. 


A téma iránt érdeklődőknek ajánljuk a WSH és a Netacadé- 
mia Exchange Serverek biztonságáról szóló tanfolyamát, ér- 
deklődjön e-mailben! 


Soós Tibor (MCSEsI, MCT) 


WSH Oktatóközpont 
t.soos Owsh.hu 
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TIransact SOL 2. rész 


Összetett lekérdezések 

Cikkünk előző részében elindultunk a Microsoft 
SOL 2000 programozásának izgalmas útján. 
Megnéztük, hogyan írhatunk egyszerű lekérde- 
zéseket, amelyekkel apróbb feladatokat adha- 
tunk az adatbázisnak. Ebben a részben jobban 
belemélyedünk a lekérdezések lelkivilágába, és 
megnézzük, hogy komolyabb feladatokat ho- 

gyan oldhatunk meg a Transact SOL segítségével. 





Még mindig együtt! 

Előző cikkünk végén az illesztésekkel (JOIN) foglalkoztunk, és 
eljutottunk odáig, hogy illesztés segítségével logikailag össze- 
tartozó, de fizikailag több táblára szétdarabolt adatokat újra 
egyesíthetünk. Megbeszéltük, hogy az INNER JOIN segítségével 
meg lehet találni az összetartozó sorokat. Megnéztük, hogy 
vannak olyan esetek, amikor nemcsak a párok érdekesek, ha- 
nem szükség van azokra a sorokra is, amelyekhez nincs kapcso- 
lódó sor más táblákban, ilyenkor használtuk az OUTER JOIN-t. 
A LEFT és a RIGHT OUTER JOIN segítségével kilistáztathattuk 
azokat a sorokat is, amelyeknek nem volt párja a másikban. 
Az OUTER JOIN eddig még nem említett válfaja a FULL 0U- 
TER JOIN. Ez mindkét tábla tartalmát kilistázza, függetlenül 
attól, hogy talált-e egyezést a másik táblában, vagy sem. En- 
nek felhasználása már elég speciális. Például a Northwind 
adatbázis Customers és Orders táblái között egy LEFT OUTER 
JOIN-nak van értelme, hisz kilistázza azokat a vásárlókat, 
akiknek nincsenek megrendeléseik. A fordított helyzet (egy 
jól megtervezett és implementált adatbázisban) elvileg elő 
sem állhat, azaz, hogy vannak olyan megrendelések, ame- 
lyekhez nincs megrendelő. Ez a hivatkozási (referential) in- 
tegritás megsértése volna, hisz az Orders táblában van egy 
idegen kulcs (foreign key) a Customers táblára. Ennek ellené- 
re a gyakorlatban sokszor előfordul, főleg, amikor egy régeb- 
bi rendszerből költöztetünk adatokat egy újabba, hogy bi- 
zony sok helyen baj van az adatok épségével. Tegyük fel, 
hogy az előbb említett két táblát egy másik adatbázisból 
kaptuk, és az a feladatunk, hogy állapítsuk meg, rendben 
vannak-e a hivatkozási szabályok. Mi sem egyszerűbb: 


SELECT 
Customers . CustomerID, 
Customers . CompanyName , 
Orders .CustomerID 
FROM 
Customers 
FULL OUTER JOIN 
Orders 
ON 
Customers .CustomerID - Orders.CustomerID 
WHERE 
Orders.CustomerID IS NULL OR 
Customers.CustomerID IS NULL 


Mit várunk a lekérdezéstől? Azt, hogy kilistázza az összes 
megrendelést, amelynek nincs gazdája (Customers.Custome- 
rID IS NULL), és kilistázza azokat a vásárlókat, akiknek nincs 
megrendelése (Orders.CustomerID IS NULL). Az adatok értel- 
mezését figyelembe véve csak az előbbi valódi probléma, az 
utóbbi nem. Ez azért van, mert logikailag a Customers és az 
Orders tábla között egy vagy több kapcsolat van, azaz min- 
den tételhez a Customers táblában tartozhat nulla vagy több 
tétel a másikban. Ennek megfordításaként viszont minden 


egyes tételhez az Orders táblában kell lennie egy megfelelő 
tételnek a Customers táblában. A teljesség kedvéért íme a le- 
kérdezés kimenete, melyből látszik, hogy nincs árva megren- 
delés (ahol az első CustomerID NULL értékű lenne): 


CustomerID CompanyName CustomerID 
FISSA FISSA Fabrica S.A. NULL 
PARIS Paris spécialités NULL 


Az illesztések közül már csak egy maradt hátra, amelyet csak 
nagyon ritkán, elsősorban tesztadatok generálására haszná- 
lunk. Ennek neve CROSS JOIN, és a matematikából ismert Des- 
cartes szorzatot valósítja meg. Adatbázisra lefordítva ez azt 
jelenti, hogy az első tábla minden sorát összepárosítja a má- 
sik tábla minden sorával, azaz tulajdonképpen egy speciális 
INNER JOIN, amelynek feltétel része (ON ...) mindig igaz. 
Nézzük meg, hogy a CROSS JOIN segítségével hogyan lehet 
kevés kiinduló adatból nagyszámú tesztadatot generálni! 
Tegyük fel, hogy teszt felhasználókra van szükségünk. Ki- 
indulásként felvittük kilenc személy vezeték- és keresztne- 
vét egy táblába (Employees), azt szeretnénk, hogy a veze- 
ték- és keresztnevek kombinálásával előállítsunk felhasz- 
nálói neveket. Ha minden vezetéknevet összepárosítunk 
minden keresztnévvel, akkor 9x9-81 nevet fogunk kapni. 
Hogyan néz hát ki a generáló script? 


SELECT 

El.FirstName, E2.LastName 
FROM 

Employees El 
CROSS JOIN 

Employees E2 
Robert Buchanan 
Laura Buchanan 
Anne Buchanan 
Nancy callahan 
Andrew callahan 


Két csel is el van rejtve ebben a rövid lekérdezésben. Lehet 
egy táblát önmagával illeszteni? Igen! Ezt hívják self join- 
nak. De honnan tudja a SELECT, hogy mikor melyik példány- 
ra hivatkozunk? Onnan, hogy átnevezzük őket, álnevet adunk 
nekik (alias). Így bárhol a lekérdezésben az első Employees 
táblára E1 néven lehet hivatkozni, míg a másikra E2 néven. 
Így a fordító nem fog kétségek között vergődni, hogy éppen 
mire gondoltunk. Tábla álneveket bármikor használhatunk, 
nem csak illesztések esetén. Sokszor hosszú táblaneveket rö- 
vidítünk velük, például az [Orders Details] táblát od-re. 
Maradjunk még az illesztéseknél, mert sok olyan finomság 
van bennük, amelyeket ha nem tud valaki előre, csak több 
napos bosszankodás után fogja felfedezni. 


A fránya "- 

Az illesztések formális leírásának van egy másik formája is, 
amelyet szándékosan elhanyagoltam eddig, mert elavult, és 
nem lehet vele minden feladatot egzaktul megfogalmazni. Mi- 
vel azonban nagyon sokan használják, nem hagyhatom ki a 
tárgyalásból, hisz ha már együtt kell élnünk vele, legalább is- 
merjük az árnyoldalait. Összehasonlításként leírok egy lekér- 
dezést az INNER JOIN felhasználásával, majd a régi módon: 
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SELECT 
Customers.CustomerID, 
Customers . CompanyName , 
Orders.OrderDate 

FROM 
Customers 

INNER JOIN 
Orders 

ON 
Customers.CustomerID -— 

Orders.CustomerID 


Régi módon: 

SELECT 
Customers.CustomerID, 
Customers . CompanyName , 
Orders .OrderDate 

FROM 
Customers, 

WHERE 
Customers.CustomerID -— 

"  Orders.CustomerID 


Orders 


Azaz válogassa ki azokat a sorokat a két táblából, ahol 
(WHERE) a Customers.CustomerID - Orders.CustomerID. Tel- 
jesen logikus, és nincs is vele baj. Ha keresni akarjuk a ká- 
kán a csomót (és miért ne tennénk), akkor hogy van az, 
hogy a WHERE után lehetnek olyan kifejezések, amelyek s0- 
rok szűrését végző feltételeket tartalmaznak, és olyanok is, 
amelyek táblák logikai összekapcsolását tartalmazzák? Nem 
két, teljesen különböző funkcióról van itt szó? De! És ez visz- 
sza is fog ütni mindjárt (megvan az első csomónk)! 
A probléma az OUTER JOIN-oknál kezdődik. A régebbi OUTER 
JOIN-t megvalósító kifejezés a WHERE a "- b volt, és attól 
függően, hogy a csillag melyik oldalán van az egyenlőségjel- 
nek, lehet jobb vagy bal oldali illesztést kifejezni. Ez ugyan- 
azt jelenti, mint az OUTER JOIN? (És most mindenki tegye fel 
és válaszolja meg magának ezt a kérdést, mielőtt tovább ol- 
vasna.) Nem! Nézzük meg egy példán keresztül a csalást! 
Új formátum: 
SELECT 
Customers.CustomerID, 
Customers . CompanyName , 
Orders.OrderDate 
FROM 
Customers 
LEFT JOIN 
Orders 
ON 
Customers.CustomerID -— 
Orders.CustomerID 


Régebbi formátum: 

SELECT 
Customers.CustomerID, 
Customers . CompanyName , 
Orders.OrderDate 

FROM 
Customers, 

WHERE 
Customers.CustomerID :- Orders.CustomerID 


Orders 
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A két lekérdezés kimenete azonos: 


BONAP Bon app" 1998-05-06 
RATTC Rattlesnake Canyon 1998-05-06 
PARIS Paris spécialités NULL 
FISSA FISSA Fabrica S.A. NULL 


Akkor miért kritizálom a "- formátumot? Mindjárt kiderül. 
Próbáljuk meg kiszűrni például a Bon app! céget a listából, 
ügyelve arra, hogy a LEFT JOIN által behozott NULL-okat ne 
szűrjük ki. Az új formához csak egy feltételt kell adni: 


WHERE 
Orders.CustomerID C5 !"BONAP" OR 
Orders.CustomerID IS NULL 


RATTC Rattlesnake Canyon 1998-05-06 
PARIS Paris spécialités NULL 
FISSA FISSA Fabrica S.A. NULL 


És a kimenetből tényleg eltűnt a kérdéses sor, míg a NULL- 
osok megmaradtak. Egy kis magyarázatot azért megér, hogy 
miért kell a második feltétel is, miért nem elég csak az el- 
ső. Az előző részben részletesen foglalkoztunk vele, hogy a 
NULL azt jelenti, hogy nincs adtat, így az Orders.Custome- 
rID cs BONAP" feltételnél kiesnének a NULL-okat tartalma- 
zó sorok, mert egy NULL-al végzett összehasonlításnak nem 
lehet eldönteni az igazságtartalmát. Ezért kellett bevetni az 
IS NULL-t. 

Itt az ideje, hogy kiugrasszuk a nyulat a bokorból! Írjuk át 
a lekérdezést a régi szintaxisra: 


WHERE 
(Customers.CustomerID tz 
Orders.CustomerID) AND 
(Orders.CustomerID C5 "BONAP" OR 
Orders.CustomerID IS NULL) 


És mit látunk kimenetnek? 


RATTC Rattlesnake 1998-0O5-06 
PARIS Paris spécialités NULL 
FISSA FISSA Fabrica S.A. NULL 
BONAP Bon app" NULL 


Ott virít a Bon app", pedig kiszűrtük (ráadásul lemaradt a 
megrendelése is)! Miért? Azért, mert a NULL ellenőrzése 
előbb történik meg a szerverben, mint az illesztés, így a bal 
illesztés behozza újra a kiszűrni kívánt sort. De hogy lehet- 
tünk ennyire figyelmetlenek, miért nem a Customers.Custo- 
merID-ra szűrünk, miért az Orders.CustomerID-ra. Ez biztos 
bejön! Nézzük csak: 


WHERE 
(Customers.CustomerID 1- 
Orders.CustomerID) AND 
(Customers.CustomerID C5 !BONAP" OR 
Orders.CustomerID IS NULL) 
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Nem mutatom meg a kimenetet, de még mindig benne van 
a BONAP! Hogy lehet ez? Úgy, hogy a Orders.CustomerID 
IS NULL most az illesztés után hajtódott végre, így behoz- 
ta a BONAP-ot. Szeszélyesebb az adatbázis motor, mint az 
időjárás! Vagy mégsem? 


A megoldás " 

Ne fokozzunk tovább a feszültséget! Miután rájöttünk, hogy 
az IS NULL vizsgálat hozza be a nemkívánatos sorokat, ve- 
gyük ki a lekérdezésből. 


WHERE 
(Customers.CustomerID :- 
Orders.CustomerID) AND 
(Customers.CustomerID C5 "BONAP") 


És eltűnt a Bon app! Lehet, hogy ez sok hűhó semmiért, és 
hogy ez egy olyan nyilvánvaló dolog volt, amit egy tapasz- 
talt SOL programozó azonnal kiszúr. Lehet, bár azért még 
nekik is lehet fejtörést okozni. Mert rakjuk csak be a régi stí- 
lusú külső illesztésünket egy SOL nézetbe (View). Azoknak a 
kedves olvasóknak, akik még nem használtak nézeteket, né- 
hány szó róla. Nézetekbe olyan lekérdezéseket szoktunk ,,be- 
csomagolni", amelyeket több helyen is fel fogunk használ- 
ni, így nem kell mindig leírni őket. A nézetek úgy viselked- 
nek, mintha ők valamiféle virtuális táblák lennének, ame- 
lyek a bennük található lekérdezéseket táblaként adják visz- 
sza. Na már most, tegyük fel, hogy több ember dolgozik egy 
projekten. Az egyik megírja a már sokszor emlegetett lekér- 
dezést egy nézetbe, természetesen a régi szintaxissal. Le- 
gyen a nézet definíciója: 


CREATE VIEW 
CustOrders 

AS 

SELECT 
Orders.CustomerID, 
Customers . CompanyName , 
Orders.OrderDate 

FROM 
Customers, 

WHERE 
Customers.CustomerID r- 
Orders.CustomerID 


Orders 


Ezután a tudatlanság boldogságában leledző társprogramo- 
zó ki szeretné szűrni a BONAP-ot: 


SELECT 
CustOoOrders.CustomerID, 
CustOrders . CompanyName , 
CustOorders.OrderDate 

FROM 
CustOorders 

WHERE 
CustOrders.CustomerID C5 !"BONAP" OR 
CustOorders.CustomerID IS NOT NULL 


És itt áll égnek a haja, mert a szerver látszólag nem műkö- 
dik normálisan, hisz nem szűrte ki a megfelelő sort! 
Összegezve: ne használjuk a régi formátumú illesztése- 
ket, mert félreértésekhez vezethet. Emellett a későbbi 
verziójú SOL Serverek nem fogják támogatni. Ha más nem, 
ez elégséges érv lehet. 
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Egymásba ágyazva 

Az SOL nyelv egyik leghatékonyabb eszköze, hogy a WHERE 
feltételbe nemcsak egyszerű logikai kifejezéseket írhatunk, 
hanem további lekérdezéseket is. Ráadásul a két lekérdezés 
között lehet kapcsolatot is teremteni. Például listázzuk ki 
azokat az alkalmazottakat, akik már teljesítettek megrende- 
léseket, azaz az Orders táblában van olyan sor, ami az Emp- 
loyee táblában található alkalmazottra mutat: 


SELECT 
LastName, 
FROM 
Employees 
WHERE 
Employees.EmployeeID IN 
(SELECT 
EmployeeID 
FROM 
Orders) 


FirstName 


Másképpen fogalmazva listázzuk ki az EmployeeID-kat az Or- 
ders táblából, majd az Employees táblából válogassuk le 
azokat a sorokat, amelyeknek az EmloyeeID-ja megegyezik 
valamelyik Orders táblából származó EmployeeID-val (IN). 
Ezt a lekérdezést át lehetne írni JOIN-ra is: 


SELECT 
LastName, 

FROM 
Employees 

INNER JOIN 
Orders 

ON 
Employees.EmployeeID -— 

Orders . EmloyeeID 


FirstName 


Általánosságban igaz, hogy minden JOIN-t át lehet írni egy- 
másba ágyazott lekérdezésre, de visszafelé ez nem feltétle- 
nül igaz. Azaz vannak olyan egymásba ágyazott lekérdezé- 
sek, amelyek egy egyszerű illesztésnél bonyolultabb dolgot 
valósítanak meg. Például listázzuk ki azokat a termékeket 
(Products) , amelyek ára 10 dollár alatt van, de volt olyan al- 
kalom, amikor egyszerre eladtak valamelyik termékből több 
mint 800 dollárnyit. 


SELECT 

ProductID, ProductName 
FROM 

Products AS p 
WHERE 


UnitPrice € 10 AND 
ProductID IN 
(SELECT ProductID 
FROM 
[Order Details] od 
WHERE 
od.Ouantity : p.UnitPrice 5 800) 


ProductID ProductName 

41 Jack"s New England Clam 
45 Rogede sild 

75 Rhönbrüu Klosterbier 
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Hogyan képzelhetjük el a lekérdezés működését? Az első 
SELECT végiglépked a Products tábla azon sorain, melyekben 
a UnitPrice mező értéke kisebb, mint 10. Minden kiválasztott 
sornál elindít egy belső ciklust (a belső SELECT) az Order De- 
tails táblára, és keres olyan sorokat, amelyekre teljesül a 
WHERE-ben megadott feltétel. Ennek specialitása, hogy a kül- 
ső SELECT által pillanatnyilag kiválasztott sorból származó 
adatot is felhasználja (pl.UnitPrice) . Az ilyen típusú egymásba 
ágyazott lekérdezéseket Correlated Subguery-nek nevezzük. 
Mikor érdemes használni egymásba ágyazott lekérdezéseket, 
és mikor illesztést? Az attól függ. Ha nincs különösebb kö- 
vetelmény a lekérdezés teljesítményére, akkor használjuk 
azt, ami a probléma természetes nyelvi megfogalmazásához 
legközelebb áll, így később könnyebben érthető és karban- 
tartható lesz a script. Ha fontos az optimális teljesítmény, 
akkor inkább használjunk illesztést. Miért? Illesztések ese- 
tén az optimalizáló meg tudja választani, hogy milyen sor- 
rendben hajtsa végre az utasítást, így minimalizálni tudja a 
végrehajtáshoz szükséges költséget. Egymásba ágyazott le- 
kérdezéssel beledrótozzuk a végrehajtás sorrendjét a lekér- 
dezésbe, így nem sok teret hagyunk az optimalizálónak a 
gondolkodásra. Ennek ellenére majd mutatok eseteket, ami- 
kor lassabb lesz az illesztés. A végső ítéletet csak a lekérde- 
zés költségének vizsgálatával lehet kimondani (Ouery Analy- 
Zer, Show Execution Plan). 


A duplikált adatok problémája 

Van egy elég gyakori feladat, amelynek megoldása első ne- 
kifutásból nem kézenfekvő. Nevezetesen, hogy keressük 
meg egy táblában az ismétlődő sorokat. Leginkább ez is 
adatmigrációnál jön elő, amikor az SOL Serverbe bemásolt 
adathalmaz egy oszlopára szeretnénk ráadni egy UNIOE vagy 
PRIMARY KEY-t, de van benne egy-két ismétlődő sor, ami 
megakadályozza ezt. Ilyenkor meg kell keresni azokat a s0- 
rokat, amelyekben azonosak a kérdéses oszlopok értékei. Ez- 
zel ugye az a baj, hogy a WHERE egyszerre mindig csak egy 
sorral foglalkozik. Hogyan lehetne rávenni, hogy ugyanan- 
nak a táblának a sorait hasonlítgassa össze egymással? A 
megoldás egy self-join. , Sajnos" a Northwind egy konzisz- 
tens adatbázis, így abban nem fogunk találni olyan dupli- 
kált sorokat, amelyeket ki lehetne szűrni, mint logikailag hi- 
básakat. Ezért a példa kedvéért nézzük a következő táblát 
(Users): 


nID FirstName LastName BirthDay 


d István Király 1954-05-22 
2 László Lőrincz 1961-11-14 
3 Jenő Rejtő 1910-01-14 
4 Jenő Rejtő 1910-01-14 


Tegyük fel, hogy ezt a táblát úgy kaptuk, hogy kiindulásként 
volt egy HR-től kapott konszolidálatlan felhasználói adatbá- 
zis Excel-ben, amit például a Data Transformation Services 
segítségével beimportáltunk egy Users nevűtáblába. Azért, 
hogy tudjunk hivatkozni a sorokra, adtunk mindegyiknek 
egyedi azonosítót egy szám formájában. Szeretnénk megta- 
lálni azokat az embereket, akik többször is szerepelnek a táb- 
lában. Tegyük fel, hogy két sort (és embert) akkor mondunk 
azonosnak, ha a vezeték- és keresztnevük azonos, valamint 
egy napon születtek. Keressük hát meg, ki a kakukktojás! 


ADJ) ága da ISzeu A 
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SELECT 
ul.nID, ul.FirstName, 
ul.LastName, ul.BirthDay 
FROM 
Users ul 
INNER JOIN 
Users u2 
ON 
ul.FirstName — 
ul.LastName 
ul.BirthDay 
WHERE 
-- Máskülönben minden sornál megtalálná 
-- önmagát, mint a sajt párját! 
ul.nID C5 u2.nID 


u2.FirstName AND 
u2.LastName AND 
u2.BirthDay 


Az eredményen remélem senki nem lepődik meg: 


nID FirstName LastName BirthDay 
3 Jenő Rejtő 1910-01-14 
4 Jenő Rejtő 1910-01-14 


Mi itt a szokatlan? Az, hogy illeszteni lehet több mezőre is, sőt 
nem csak numerikus mezőkre! Általában az él a legtöbb fej- 
lesztőben, hogy biztos, ami biztos, minden táblához generá- 
lok egy mesterséges kulcsot (Surrogate Primary Key), és azon 
keresztül illesztem a táblákat. Ez helyes, ha gyors adatbázist 
akarunk építeni, de azért nem csak egy egész szám lehet 
gyors. Mi van például a 2-3-4 betűs azonosítókkal? Azokat ta- 
lán lassabb összehasonlítani, mint az egészeket? Nem sokkal, 
viszont sokkal könnyebben átlátható adatbázist kapunk. 
Például egy felhasználói adatbázisban az osztály, ahol az al- 
kalmazott dolgozik valószínűleg egy külön táblában lesz el- 
tárolva. Numerikus kulcsokat használva az IT 1 lesz, a Finan- 
ce 2 satöbbi. Ezzel szemben egy 3 karakteres azonosítóval 
az IT lehet IT, a Finance "Fir, a Human Resources "HR" és 
így tovább. Így a felhasználói táblát böngészve nem "Kiss 
József, "2-t fogunk látni, hanem "Kiss József, "Finf-t, ami 
azért könnyebben dekódolható, nem? 


Zárszó 

A következő számban még további lekérdezéseket írunk a 
GROUP BY, a HAVING és társaik segítségével, hogy csodaszép 
statisztikákat tudjunk generálni. Mindenkit visszavárok! 


Soczó Zsolt MCSE, MCSD 
Protomix Rt. 












A Network Load Balancing (továbbiakban NLBS) a 
Windows 2000 Advanced Server és a Windows 
2000 Datacenter Server operációs rendszerek 
beépített szolgáltatása. Az NLBS nagyobb 
rendelkezésreállást és stabilitást biztosít az 
Internet-kiszolgáló alkalmazások (például 
web- vagy FTP-kiszolgálók, és más, nagy fon- 
tosságú kiszolgálók) számára. A Windows 2000-t 
futtató számítógép önállóan a nagy rendel- 
kezésreállási elvárásoknak csak korlátozottan felel 
meg, de az NLBS segítségével fürtbe rendezett Windows 
2000 Advanced Server-ek kielégítik a nagy fontosságú és 
-rendelkezésreállású rendszerekkel szemben támasztott 
biztonsági és teljesítmény-elvárásokat. 
A szükséges kiszolgáló-alkalmazások (web-, FTP-, telnet-, 
vagy levelező-kiszolgálók) a fürt minden tagkiszolgálóján 
futhatnak. A szolgáltatások egy része (például a webkiszol- 
gáló) az összes tagkiszolgálón egyidejűleg működik, az 
NLBS pedig a beérkező hálózati terhelést elosztja a tagok 
között, míg más szolgáltatásokat (például a levelezést) egy- 
idejűleg csak a fürt egy tagkiszolgálója látja el. Minden 
esetben az NLBS feladata, hogy hiba esetén a kiesett ki- 
szolgáló forgalmát egy másik, működő taghoz irányítsa át. 


Az NLBS működéséhez szükséges konfiguráció 

A Windows 2000 NLBS szolgáltatása hálózati meghajtóként 
működik, méghozzá olyan alacsony szinten, hogy a TCP/IP 
hálózati összetevők az NLBS jelenlétét nem is észlelik. 

A legjobb teljesítmény elérése érdekében az NLBS általában szá- 
mítógépenként két hálózati csatolót használ: az egyik csatoló 
feladata az ügyfelek kiszolgálása (mint rendesen) , a másik pedig 
az NLBS fürt , adminisztratív" hálózati forgalmát kezeli. Termé- 
szetesen nincs akadálya annak sem, hogy minden forgalom gé- 
penként egyetlen hálózati csatolón keresztül bonyolódjon. 


Az NLBS fürt-alkalmazások adatbázis-elérése 

Sok kiszolgáló-alkalmazás működése közben adatbázisban dol- 
gozik. Ha egy fürtben több ilyen alkalmazás működik egyide- 
jűleg, akkor különös gondot kell fordítani az adatbázis-műve- 
letek szinkronizálására. Egyszerűbb esetben minden tagkiszol- 
gáló dolgozhat a saját, offline adatbázis-másolatán, majd 
szükség esetén a változásokat frissítik (migrálják) egymás kö- 
zött, vagy a központi, , valódi" adatbázisban. Máskor egyide- 
jűleg, hálózaton keresztül érik el az adatbázis-kiszolgálót, de 
előfordulhat a fenti két eset kombinációja is. Például: a 
weblapok forrásállományait nyugodtan felmásolhatjuk az 
összes tagkiszolgálóra, így rövidebb válaszidőt és nagyobb hi- 
batűrést kapunk. A weblapokon keresztül érkezett adatbázis- 
elérést igénylő műveleteket ugyanakkor kezelheti különálló, 
megbízható adatbázis-kiszolgáló, amely egyszerre az összes 
tagkiszolgálót ellátja. 

A fontos vállalati alkalmazások a hibatűrő szolgáltatás bizto- 
sítása érdekében nagy rendelkezésreállású adatbázis-konfigu- 
rációt igényelnek. Ilyenkor maga az adatbázis kiszolgáló is 
fürtbe rendezett számítógépeken fut, így biztosítja a nagy ren- 
delkezésreállást és a méretezhetőséget. Ilyen adatbázis-kiszol- 
gáló lehet például a Cluster szolgáltatás segítségével megvaló- 
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sított kétpontos fürtre telepített Microsoft SOL Server. A Clu- 
ster szolgáltatás biztosítja, hogy ha a két csomópont közül az 
egyik kiesik (a csomópontot megvalósító számítógép meghibá- 
sodik), a másik csomópont átveszi a hibás egység feladatait. 
Teheti mindezt azért, mert a fürt két csomópontja közös me- 
revlemez-alrendszert használ. Az SOL Server ügyfelei pedig az 
átállásból csaknem semmit sem vesznek észre. 

Fontos, hogy a két fürtözési módszert megkülönböztessük 
egymástól. Az első, az NLBS fürt feladata elsősorban a beér- 
kező TCP/IP hálózati forgalom elosztása a rendelkezésre álló 
tagkiszolgálók között. Ezek a független tagkiszolgálók egy 
NLBS fürtöt képeznek. A második módszer a Cluster szolgál- 
tatás segítségével megvalósított fürt, amelyet két vagy több, 
fizikailag szorosan összekapcsolt, közös lemez-alrendszert 
használó számítógép valósít meg. A Cluster szolgáltatás se- 
gítségével leggyakrabban nagy rendelkezésreállású adatbá- 
Zis-kiszolgálókat építenek (amit azután természetesen akár 
NLBS fürtök háttérkiszolgálójaként is lehet használni). A két 
fürttípus együttes használatával teljeskörű, hibatűrő és nagy 
rendelkezésreállású fürtkörnyezetet teremthetünk. 


A hálózati terheléselosztás működése 

A hálózati terheléselosztás segítségével megbízható és mé- 
retezhető hálózati kiszolgálót hozhatunk létre két vagy 
több tagkiszolgáló számítógép fürtbe rendezésével. Az in- 
ternetes ügyfelek a fürtöt a fürt saját IP címén (címein) ke- 
resztül érik el. Az ügyfelek számára a fürthöz való csatlako- 
zás ugyanolyan, mintha közvetlenül a fürt egy tagkiszolgá- 
lójához kapcsolódtak volna; a kiszolgálón futó alkalmazá- 
sok sem észlelik, hogy egy fürtbe rendezett számítógépen 
futnak. (A Cluster fürt előnyeit csak speciális, erre tervezett 
alkalmazások képesek kihasználni.) Az NLBS fürt azonban 
mégsem ugyanolyan, mintha több különálló számítógépen 
futtatnánk az alkalmazásokat, hiszen a tagkiszolgáló hibá- 
ja esetén a szolgáltatás nem szakad meg, csak a bejövő há- 
lózati kapcsolatok átkerülnek a fürt még működő tagkiszol- 
gálóihoz. A fürt ezen kívül - a terheléselosztással működő 
portokon - nagyobb hálózati terhelést képes elviselni, mi- 
közben gyorsabb válaszidőt biztosít az ügyfelek számára. 
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Ha egy NLBS fürt tagkiszolgálója meghibásodik, a Network 
Load Balancing a beérkező hálózati forgalmat automatikusan 
a még működő tagkiszolgálók között osztja el. A leálló tag- 
kiszolgálóval létesített hálózati kapcsolatok elvesznek, de a 
szolgáltatás a fürtben továbbra is elérhető marad. A legtöbb 
esetben (például webkiszolgálók esetén) az ügyfélszoftver au- 
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tomatikusan újra megpróbálkozik a megszakadt kapcsolatok 
felépítésével (tudtán kívül, de ezúttal már egy másik, még 
működő tagkiszolgálóval), az ügyfél pedig ebből mindössze 
csak a néhány másodperces várakozást veszi észre. 

Az NLBS a fürt egy vagy több saját IP címére érkező háló- 
zati forgalmat elosztja a rendelkezésre álló tagkiszolgálók 
között. A tagkiszolgálók egyidejűleg válaszolnak a külön- 
böző ügyfelek kéréseire, akár egy ügyfél több kérésére is. 
Például: az ügyfél által megtekintett weboldal forráskódja 
a fürt egyik, míg az oldalon található képek a fürt egy má- 
sik tagkiszolgálójáról érkezik. Ez meggyorsítja a kiszolgá- 
ló-műveleteket és csökkenti a válaszidőt. 

Az NLBS fürt minden - közös alhálózaton található - tagki- 
szolgálója észleli a teljes bejövő hálózati forgalmat. A tag- 
kiszolgálókon található NLBS eszközmeghajtó szűrőként mű- 
ködik a fürtre csatlakozó hálózati kártya és a számítógép 
TCP/IP komponensei között: a bejövő forgalom egy részét 
továbbengedi, más részét elnyeli (a TCP/IP nem is tud róla, 
hogy fürtben működik - hiszen hozzá már csak az a hálóza- 
. ti forgalom jut el, amit az NLBS eszközmeghajtó jónak lát). 
A Network Load Balancing teljesen elosztott algoritmus se- 
gítségével az ügyfél IP címe, a port és egyéb információk 
alapján rendeli a beérkező kéréseket a tagkiszolgálókhoz. A 
beérkező csomagokat minden tagkiszolgáló megkapja és ki- 
elemzi, majd az algoritmus segítségével eldönti, melyik tag- 
kiszolgáló dolgozza fel a kérést. Ez a hozzárendelés egészen 
addig érvényben marad, míg a fürtben található tagkiszol- 
gálók száma meg nem változik. Az NLBS szűrő algoritmus 
sokkal hatékonyabb és nagyobb sávszélesség kiszolgálására 
képes, mint a központosított terheléselosztó megoldások, 
amelyekben a központi egység a hálózati csomagokat módo- 
sítja, majd továbbküldi a megfelelő tagkiszolgálóhoz. Az 
NLBS a tagkiszolgálókon fut, így működése nem korlátozó- 
dik adott processzortípusokra vagy hálózati megoldásokra. 


A hálózati forgalom elosztása 

Az NLBS a következő módon osztja el a beérkező Transmis- 
sion Control Protocol (TCP) és User Datagram Protocol 
(UDB) csomagokat a tagkiszolgálók között: a fürt saját IP 
címére érkező csomagokat a fürt minden tagkiszolgálója 
megkapja, majd az NLBS szűrők a csomagokban használt 
TCP és UDP portok alapján megszűrik ezt a forgalmat, mi- 
előtt azok még a TCP/IP meghajtót elérnék. 

Az NLBS csak a TCP és UDP csomagokat dolgozza fel, nem 
szűri a beérkező Internet Control Message Protocol (ICMP), 
Internet Group Membership Protocol (IGMP), az IP- és há- 
lózati címek (MAC address) összerendelésére használt Add- 
ress Resolution Protocol (ARP) és más IP protokollokat 
sem. Minden ilyen forgalom akadály nélkül továbbítódik a 
tagkiszolgálók TCP/IP meghajtói felé. A TCP/IP felépítésé- 
ből következik, hogy nem okoz gondot a fürt IP címéről, 
több tagkiszolgálótól egyidejűleg érkező többszörös vá- 
lasz, bár ez a pont-pont alapú TCP/IP alkalmazások (példá- 
ul a ping) esetén probléma lehet. Ilyenkor a tagkiszolgá- 
lók saját, közvetlen IP-címét kell használni. 
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A hálózati terheléselosztás szabályainak beállítása 


Konvergencia 

Az NLBS fürt tagkiszolgálói szabályos időközönként broad- 
cast vagy multicast üzenetekkel hangolják össze a műkö- 
désüket, és felügyelik a fürt működését. Amikor a fürt ál- 
lapota megváltozik (ez történhet egy tagkiszolgáló leállásá- 
val, kilépésével vagy éppen megjelenésével) , a fürtben elin- 
dul egy folyamat, melyben a tagkiszolgálók feltérképezik a 
fürt új állapotát, és alap értelmezett tagot választanak (ez 
a legkisebb prioritású tagkiszolgáló lesz). Ezt a folyamatot 
nevezzük konvergenciának. Miután ez megtörtént, a Win- 
dows 2000 eseménynaplójában megjelennek a konvergen- 
cia befejezésére utaló bejegyzések. 

A konvergencia alatt a kiesett tag kivételével minden kiszol- 
gáló folytatja a működést, a változás a még működő tagok- 
kal létesített hálózati kapcsolatokat nem érinti. A konver- 
gencia befejeztével a kiesett tagkiszolgáló felé létesített há- 
lózati kapcsolatokat a még működő tagkiszolgálók átveszik. 
A hálózati forgalom úgy oszlik el a tagkiszolgálók között, 
hogy a hálózati terhelés egyenletes maradjon. Ha a fürtben 
új tagkiszolgáló jön létre, a konvergencia során belép a fürt- 
ben működő tagkiszolgálók sorába. A fürt bővítése nem za- 
varja a meglévő hálózati kapcsolatokat, sem az ügyfél-, sem 
a kiszolgáló-alkalmazásokat. A több TCP kapcsolatot egyide- 
jűleg használó alkalmazásoknál azonban előfordulhat, hogy 
a konvergencia során - az affinitás ellenére - a két TCP kap- 
csolat különálló tagkiszolgálóra kerül. (Hiszen az affinitás 
csak a fürt felépítésének megváltozásáig érvényes.) 

A Network Load Balancing fürt tagkiszolgálója addig szá- 
mít ,élőnek", míg az folyamatosan részt vesz a fürt tagki- 
szolgálói között folyó kommunikációban. Ha a tagkiszolgá- 
lók adott ideig nem kapnak üzenetet egy másik tagkiszol- 
gálótól, azt hibásnak veszik, és megkezdődik a konvergen- 
cia a kieső tagkiszolgáló terhelésének elosztására. Az üze- 
netek közötti időtartam és a konvergencia indításáig kima- 
radó üzenetek száma beállítható, az alapértelmezés 1000 
ms (egy másodperc), és 5 kihagyott üzenet. Mivel ezek a 
paraméterek ritkán változnak, a Network Load Balancing 
dialógusablakából nem módosíthatók: értékük szükség 
esetén a regisztrációs adatbázisban változtatható meg. 
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Hitelesítés 
A Windows 2000 biztonságát bemutató soroza- 
tunkban foglalkozzunk a hálózat biztonságá- 
val, a hálózaton átmenő jelszavak életével 
egy kicsit! Megismerjük az azonosítás alapja- 
it, s példákon keresztül megnézzük, hogy mi- 
lyen lehetőségünk van vegyes környezetben 
üzemelő hálózatok biztonságosabbá tételére. 
Végül készítünk egy házirendfájlt (policy), amivel 
a hálózat összes gépén egyidejűleg ki- vagy bekap- 
csolhatjuk, illetve szabályozhatjuk az NTLMv2 - t, mely óri- 
ási segítséget nyújt a hálózat biztonságának megőrzésében 
azzal, hogy a jelszavak titkosítására sokkal jobb algoritmust 
használ, mint elődei. Gondoljuk csak végig, hogy naponta 
a hálózatukon hányan és hányszor jelentkeznek be, mind- 
annyiszor elküldve jelszavukat! Az olvasótábor egyik fele 
nyilván tudja ezt a tényt, s biztosra veszem, hogy olyanok 
is vannak szép számmal, akik a veszélyeket is átlátják, má- 
sok azonban talán nem foglalkoztak részletesen a bejelent- 
kezéssel - nekik új információval szolgálhatok. Hát nézzük 
meg közösen, hogy miről is van szó! 





A hálózat biztonsága 

Tulajdonképp mit is értünk a hálózat biztonságán? Egy biz- 
tonságos hálózatban egyaránt helyet kap a felhasználói 
adatok védelme, a kiszolgálók fizikai védelme, a szalagos 
mentések megfelelő tárolása, az azonosítási folyamat ada- 
tainak biztonságos csatornákon történő továbbítása és 
egyéb óvintézkedések. Különböző mélységű azonosítási 
szinteket állapíthatunk meg, ahol a nagyobb mélység a 
biztonságosabb hálózatot jelenti. 


Egymélységű azonosítás 

A ,Tudok valamit" elve érvényesül. Tudok egy jelszót és a 
hozzátartozó felhasználónevet és az azonosításhoz ez ele- 
gendő. Könnyen és gyorsan beláthatjuk, hogy ez nem nyújt 
elegendő biztonságot minden hálózaton, mert Sherlock 
Holmes titkos adataihoz akár Dr. Watson is könnyedén hoz- 
záférhet, ha Mr. Holmes felhasználónevét és jelszavát hasz- 
nálja. Ha megfelelő szabályokat figyelembe véve használja 
jelszavát és felhasználónevét Mr. Holmes, akkor már megfe- 
lelő védelmet nyújthat ez is. Természetesen hálózati anali- 
zátort használva és a HASH-t elkapva a visszafejtés nem le- 
hetetlen. (Erre nyújt megfelelő védelmet a KERBEROS és az 
NTLMv2 együttes használata.) A megfelelő jelszóhasználati 
szabályokat ilyenkor is figyelembe kell venni, ilyen lehet a 
jelszavak rendszeres cseréje és megfelelő tárolása (az a jel- 
szó nem jelszó, ami le van írva). 


Kétmélységű azonosítás 

Itt a , Tudok valamit és a birtokolok valamit" elve érvénye- 
sül. Tudok egy jelszót, a hozzátartozó felhasználónevet és 
birtokomba van valami. Ebben az esetben a különbség az 
előző módszerhez képest, csak a valami, :) birtokomban van 
egy tárgy, ami mondjuk egy SmartCard. A kétmélységű azo- 
nosítás az előző példa egyetlen hibáját küszöböli ki, az pe- 
dig a jelszó és a felhasználónév illetéktelen kezekbe kerü- 





lése. Semmit sem ér az érvényes jelszó, ha nincs a birto- 
kunkban - például - egy SmartCard. 100 9o-os biztonságot 
ez sem tud nyújtani, mert a SmartCard is hamisítható, de 
körülményesebb és a költségei is lényegesen magasabbak, 
mint egy jelszó megszerzésének. Jó, megfelelő biztonságot 
tud nyújtani a tipikus vállalati hálózatoknak. További nagy 
előnye, hogy a Microsoft Windows 2000 tartalmazza a 
SmartCard azonosítás használatát. 


Hárommélységű azonosítás 

Ilyenkor a , Tudok valamit, birtokolok valamit és tudom ma- 
gam azonosítani" elve érvényesül. Tudok egy jelszót, a hoz- 
zátartozó felhasználónevet, birtokomba van valami, és két- 
séget kizáróan tudom magam azonosítani. A kétmélységű 
azonosítást fejleszti tovább ez a módszer, ami azáltal nyújt 
többet, hogy kétséget kizáróan tudom magam azonosítani 
(például egy DNS molekulával, egy ujjlenyomattal, vagy írisz- 
vizsgálattal) . Ilyen szintű biztonságot egy - két katonai bá- 
zison tapasztalhatnánk - de oda avatatlan szemek nem jut- 
hatnak be. Azt hiszem említenem sem kell, hogy ez sem 
nyújt megfelelő biztonságot, mert nincsenek olyan az el- 
lenőrző eszközök, melyeket nem lehet becsapni. Engedjék 
el a fantáziájukat és gondolják végig, hogy hogyan lehet 
ezt a módszert hamisítani és feltörni! 


Az elmélet csak elmélet, de mit mutat a gyakorlat? 

A gyakorlat azt mutatja, hogy a biztonság eddig csak né- 
hány küldetéskritikus alkalmazás esetén tűnt fontosnak, a 
cégek azok fejlesztésére fektettek hangsúlyt. Ilyen alkalma- 
zások a webkiszolgálók, az online áruházak, a banki alkal- 
mazások. Kevesebbet hallottunk eddig a LAN-ok és WAN-ok 
megfelelő biztonságának bevezetéséről. A Microsoft operá- 
ciós rendszerei ennek lehetőségét a kezdektől magában 
hordozzák. A megfelelő biztonság napjaink fontos kérdésé- 
vé válhat az intranetek mind komolyabb terjedésével. Az 
olyan hálózatok esetén, ahol egymélységű azonosítást 
használunk (azaz a magyarországi hálózatok közel 10099- 
ánál) nem elegendő a fájl- vagy megosztásszintű védelem, 
védenünk kell a felhasználó személyes azonosító adatait is. 
Saját tapasztalataim sajnos azt mutatják, hogy - akár nagy- 
vállalati szinten - a felhasználók nem megfelelően képzet- 
tek, a jelszó használatának legelemibb szabályait sem tart- 
ják be - gyakran a monitorra ragasztják a jelszavas cetlit. 
Napjainkban, amikor a telefonnak is PIN kódja van, a jel- 
szavak megfelelő használata elengedhetetlenül fontos (len- 
ne). A ,jelszó olyan mint a fogkefe: mindennap használjuk 
és sűrűn kell cserélni" idézetet ne felejtsék el! Mit tehet a 
rendszergazda, ha munkáját a felette álló vezetés határoz- 
za meg, emiatt nem állíthatja be, hogy a jelszavak 21 nap 
múlva lejárjanak? Nem beszélhetünk biztonságos hálózat- 
ról, ha a felhasználónak a jelszava nem jár le és nem kell 
megváltoztatni az alap értelmezett jelszót! Persze a rend- 
szerek gazdája - ez a leleményes ember - erre is kitalál va- 
lamit és az alap értelmezett jelszót felhasználófüggővé te- 
szi, ezzel is csökkentve a biztonsági rések számát! Másik le- 
hetőség, ha a hálózaton utazó csomagok útját teszi bizton- 
ságossá. Hogy lehet ezt megtenni? 








Az azonosítás alapja (tördelő algoritmus) 

A jelszótitkosítás egyik elterjedt módja a tördelő algorit- 
mus használata. Míg a ,hagyományos" titkosítás kétirányú 
folyamat, ami azt jelenti, hogy a titkosított adatból az ere- 
deti előállítható, addig a tördelés egyirányú folyamat (amit 
egyszer titkosítottam, abból többé nem állítható elő az ere- 
deti). Egy másik hasonlattal élve a tördelő algoritmus 
olyan, mint a húsdaráló: felül bemegy az ínycsiklandozó ka- 
raj, alul kijön a darált hús, amiből már soha az életben nem 
lesz többé karaj, maximum fasírt. Az egyetlen lényeges kü- 
lönbség a húsdaráló és tördelő algoritmus között az, hogy 
a HASH-ek jellemzőek az eredeti adatra, azaz helyettük fel- 
használhatók azonosításra, míg a darált hús nemigen lenne 
egyértelmű helyettesítője a karajnak... Nem tűnik túl prak- 
tikus eljárásnak, ugye? De gondoljuk végig, ha én nem tu- 
dom visszafejteni a HASH-ből az eredeti jelszót, akkor sen- 
ki más sem, ami azt jelenti: az adat biztonságban utazik a 
hálózaton! A bejelentkezés tördelő algoritmust használó 
hálózat esetén nagyon egyszerű, ilyet használ a Windows 
NT is. A bejelentkezni kívánó gép elküldi a tartományvezér- 
lő számára a felhasználó jelszavából képzett HASH-t. Ezek 
után a kiszolgáló a nála tárolt jelszó adataiból szintén elő- 
állítja a HASH-t és ha a két HASH megegyezik, akkor a jel- 
szó helyes, a felhasználó azonosítva. A Microsoft kétféle 
megvalósítást kínál a tördelő algoritmus használatához. Az 
egyik a LanMan - ami elég gyenge megoldás, és általában 
csak kompatibilitási okokból használjuk (ha a hálózatban 
Win9x-ek is vannak), - a másik pedig a Challange/Respon- 
se - ami már komolyabb, nehezebben megfejthető, a hús- 
darálóhoz közelebb álló tördelést biztosít Windows NT és 
Windows 2000 munkaállomások számára. 


Tartományvezérlő 


Ügyfél 
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Az azonosítás folyamata 


Challenge/Response (kihívás/válasz): 

Az előzőek alapján tudhatjuk, hogy a Challenge/Response 
azonosítás tördelő algoritmust használ. Úgynevezett fű- 
szerezett (salted, sózott) algoritmusról van szó, amely azt 
jelenti, hogy az algoritmus kimenete nemcsak a tördelen- 
dő bemenettől, hanem egy csipetnyi módosítókódtól (ez a 
fűszer) is függ. (Automatikusan fűszerező húsdaráló.) A fű- 
szer lehetővé teszi, hogy a HASH mindig egy picit másmi- 
lyen legyen, ezzel is nehezítve a jelszótolvaj dolgát. Fel- 
merülhet a kérdés, hogyan lehetséges, hogy mind a kiszol- 
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gáló mind az ügyfél a jelszóból ugyanazt a HASH-t állítja 
elő? Ez csak úgy lehetséges, ha mindketten azonos módo- 
sítókódot használnak a HASH előállításához - azt pedig 
nyilván meg kell beszélniük, azaz át kell küldeni a hálóza- 
ton. Jogos lehet a kérdés, ha a kód átmegy a hálózaton azt 
elkapva a csomagok nem nyithatók-e ki? Elvileg nem, mert 
ezek a kulcsok egyediek és egyszer használatosak. Nem 
lenne értelme egy egyszer használatos kulcsot elkapni, ha- 
csak a kulcshoz tartozó HASH-t nem tudom elkapni. Az 
azonosítást tehát megelőzi egy egyeztetés, ami a Challenge 

/Response esetén az alábbiak szerint zajlik : 

1. A felhasználó számítógépe jelzi a kiszolgálónak, hogy 
be szeretne jelentkezni. Kiss Pista begépeli a jelszavát, 
ami a tartományvezérlő SAM adatbázisban is megtalál- 
ható, így alapot ad az összehasonlításra. 

2. A kiszolgáló visszaküld egy 8 bájtos KIHÍVÁST (salt), 
ami a következő pontban történő titkosítás alapját képezi. 

3. A -CKiss Pista által begépelt jelszót a felhasználó számí- 
tógépe a salt felhasználásával titkosítja, és előáll a 
HASH, a válasz. 

4. A felhasználó gépe visszaküldi a HASH-t és Kiss Pista 
felhasználónevét. 

5. A kiszolgáló a visszaküldött , csomagból" kiolvassa a 
felhasználó nevét. Ez alapján a SAM adatbázisból elő- 
keresi jelszavát és ebből ő is előállítja a választ. 


t Hash 1. Be szeretnék jelentkezni Xs Hash 
2. Ezt használd titkosításkor! (KIHÍVÁS) fi 
4. Név, VÁLASZ (a jelszó helyett) Lo] E 
6. Rendben/Elutasítva a ia 
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Két lehetőség marad, a tartományvezérlő, és a felhasználó gé- 
pe által előállított HASH vagy megegyezik, vagy nem. Ennek 
megfelelően a bejelentkezés vagy elutasítva, vagy elfogadva. 
Ez képezi a Challenge/Response hitelesítés alapját, ami két 
gép között még elegendő biztonságot nyújt. Viszont ha a 
hálózatunkban levő munkaállomások számát növeljük, és 
abból kiragadunk két felhasználói gépet és egy tartomány- 
vezérlőt, akkor máris láthatjuk, hogy a csomagok a hálóza- 
ton indokolatlanul többször utaznak. Ha Kiss Pista el sze- 
retné érni Nagy József gépének egy erőforrását, akkor el- 
járás az első 4 pontja azonos lesz a fentivel. Viszont az 5. 
pontban Nagy József gépe észreveszi, hogy az ő SAM adat- 
bázisában nincs bent Kiss Pista felhasználó. Ekkor az egész 
csomagot, (KIHÍVÁS, FELHASZNÁLÓNÉV, VÁLASZ) átküldi a 
tartományvezérlőnek, és ő dönti el a hitelességet. Ekkor a 
hálózaton már kétszer átment a csomag és ez a szám csak 
növekedik, ha tartományok között történik a hitelesítés. 
Sajnos csak elmélet az, hogy a Challenge/Response mód- 
szer nem törhető fel. Itt nem említ(het)jük meg annak az 
Internetről letölthető alkalmazásnak a nevét, mellyel háló- 
zatról lelopott LanMan és Challenge/Résponse HASH-ek 
alapján a jelszavak tökéletesen visszaállíthatók. 

Ez nem titok: a LanMan és az NTLM sebezhető, támadható, 
hisz a tördelő algoritmus publikussá válásával annak gyen- 
géi is napvilágra kerültek. Az alábbi ábra az LanMan HASH 
minden hacker által ismert előállítási algoritmusa: 





0 A jelszó nagybetűsítése (első fatális hiba: a változatok 
száma felére esik). 

"? 14 bájtra feltöltés szóközökkel (második fatális hiba: a 
jelszó után mindig szóköz lesz), hogy meglegyen a 

. 112 bit hossz. 

"8 Ez 2 darab 56 bites DES kulcs (harmadik fatális hiba: a 

DES nem is HASH algoritmus!). 

Ezzel a két kulccsal titkosítják a 0x4B47532140232425 

mágikus, ám konstans számot (harmadik fatális hiba: 

nincs salt) , ebből áll elő az eredmény, a 16 bájtos , HASH". 

Ráadásul, ha a jelszó rövidebb, mint 8 karakter, akkor a 

második 8 bájt mindig 0xAAD3B435B51404EE: ránézésre 

látszik, hogy rövidebb, vagy hosszabb mint 8! 

A Microsoft éppen ezért kifejlesztett egy új azonosítást, 

melynek neve NTLMv2 és lényegesen erősebb HASH algo- 

ritmust használ, mint elődei, s melynek a mai napig nincs 

ellenszere", azaz még senkinek sem sikerült az NTLMv2 

darált húsból karajt csinálnia :) 
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NTLMv2 

A Microsoft az NTLM és a LanMan könnyű sebezhetősége 
miatt alkotta meg az NTLMv2-t, amit a Windows NT 4.0 
Service Pack 4 óta használhatunk (így a Windows2000-ben 
is elérhető). A Windows 95 és a Windows 98-as munkaál- 
lomások az NTLMv2 támogatást akkor használhatják, ha a 
Directory Services Client telepítésre kerül (a Windows2000 
CD-ROM-ról  Clients IWin9x YDsclient.exe). Ezután a Win- 
dows9x-ben megjelennek azok a fájlok, amelyek lehetővé 
teszik az NTLMv2 használatát. (Secur32.dll; Msnp32.dil; 
Vredir.vxd; Vnetsup.vxd) A telepítés után a Windows9x 
kompatibilitási okok miatt még az eredeti LanMan azono- 
sítást használja, de a következő registry értékek módosítá- 
sával le lehet erről beszélni: 


HKLMNSystemlCurrentControlSetVcontrolNLSA 
Value Name: LMCompatibilityLevel 

Data Type: REG DWORD 

Value: 3 

Valid Range: 0-3 


Az említett Registry érték Windows NT Server és Worksta- 
tion esetében is megegyezik de a Windows9X-től eltér: 


HKLMNSystemlCurrentControlSetVcontrol SA 
Value Name: LMCompatibilityLevel 

Data Type: REG DWORD 

Value: 3 

Valid Range: 0-5 


Windows2000-ben a Start menülProgramokVAd-ministrati- 
ve Tools menü alatt érhetjük el a beállításhoz szükséges 
eszközöket. (Local Security Policy; Domain Controller Secu- 
rity Policy és Doman Security Policy) GrouPolicy segítségé- 
vel is szerkeszthető az autentikáció, ez nagyban meg- 
könnyíti a munkaállomások konfigurálását. 
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Kerberos v5 

Windows2000-es tartományokban elérhetővé válik az azo- 
nosítás egy új formája a Kerberos. A Unix-világban már 
régóta jól megszokott azonosítási forma most már RFC-t is 
kapott, ennek köszönhetően a Windows2000-ben ez is el- 
érhető! Ugyan kompatíbilitási problémák adódhatnak a 
Unix és Windows 2000 között mert a Windows 2000 a 
Kerberos V5-t használja (és azért is, mert a Windows 2000 
implementáció nem hagy üresen egy olyan mezőt a Kerberos 
jegyben (AuthData), amit nem szokás kitölteni). A Kerberos 
azonosítás során nem az azonosításban résztvevő gépek 
küldik egymásnak a csomagokat, mint a kihívás/válasz 
azonosítás esetén. Itt az azonosítás folyamatában három 
gépről kell beszélnünk, ahol részt vesz egy jegykibocsátó, 
egy jegyhitelesítő és egy jegyigénylő gép. Míg a kihí- 
vás/válasz azonosítás esetén a felhasználónév és a jelszó 
(HASH) utazik a hálózaton, addig a Kerberos esetén csak 
jegyek utaznak - Triple DES kulcsokkal titkosítva. A Kerbe- 
os talán egyik legnagyobb előnye az NTLM akármelyik ver- 
ziójával szemben, hogy a kezdeti azonosítás után a fel- 
használó adataiból képzett HASH-ek NEM közlekednek ál- 
landóan a hálózaton, így teljesen értelmetlen a napközbe- 
ni hálózati forgalom elkapásával és megtörésével kísérle- 
tezni, hisz abban még darált hús sincs. 

Kerberos jegyek? Miért beszélek jegyekről? Ez Há még 
korai! Előtte még nagyon fontos fogalmat kell megvizsgál- 
nunk, ami a Windows NT 4.0 - s és Windows2000 - is tar- 
tományban is fontos szerepet játszik, ez az... 


Acces Token 

Windows NT 4.0-s tartományba bejelentkezve a felhaszná- 
lói felület megjelenése előtt kiértékelődik és letárolódik a 
felhasználó úgynevezett Access Tokenje. Az Access Token 
tartalmazza a felhasználó jogosultságainak kiértékeléséhez 
szükséges dolgokat, többek között minden csoportot, 
melynek a felhasználó tagja. Az Access Token egy igazol- 
vány, aminek felmutatásával bizonyos szolgáltatásokat 
meghatározott módon vehetek igénybe. Nagyon fontos 
megjegyezni, hogy az Access Token nem frissül azonnal, 
ha a felhasználó tulajdonságai, például csoporttagsága 
megváltozik - csak ismételt bejelentkezés esetén értékelő- 
dik ki újra. Minden erőforrás rendelkezik egy ACL-el (Ac- 





cess Controll List) ami tartalmazza, hogy mely NT-beli fel- 
használók vagy csoportok milyen jogosultsággal érhetik el. 
Egyszerűbb a dolgunk, ha azt próbáljuk elképzelni, hogy az 
Access Token tartalmazza a kulcsokat, az ACL pedig zárakat. 
A kulcsok a zárakat kinyithatják (teljesen, vagy csak fokoza- 
tosan), de lehet olyan kulcsom is, ami nem nyithatja ki sem- 
milyen körülmények közt a zárat, ilyen a NO ACCESS jogo- 
sultság, Windows 2000-ben a DENY. Windows NT 4.0 - ban 
az Access Tokennek van egy nagy hátránya: az idők végeze- 
téig érvényes. Ha egy felhasználói gépen Dr. Watson beje- 
lentkezik, Access Tokenje tartalmazza a csoporttagsági in- 
formációkat. Ha Sherlock időközben módosítja Dr. Watson 
csoporttagságát, az nem lesz hatással a munkaállomáson ki- 
értékelődött Access Tokenre. A Windows 2000 Kerberosa ter- 
mészetesen erre is nyújt megoldást. A kiadott Kerberos je- 
gyek (melyekben az Access Token megtalálható) alapértelme- 
zésben 8 óra alatt lejárnak, emiatt óránként automatikusan 
és biztosan kiértékelődik a csoporttagság és mi egyéb. A ki- 
adott jegyek nyomon követésére alkalmas eszköz a Kerberos 
" Tray, ami a Windows 2000 ResourceKit-ben található meg. 
Most, hogy megismertük az Access Token lényegét, és 
megértettük, hogy ez nem azonos a jegyekkel, nézzük meg 
a Kerberos V5 azonosítás lépéseit. 
A Kerberos V5 azonosításához szükséges szolgáltatások, az 
azonosítás folyamata: 
0 KDC (Key Distribution Center): a Triple DES kulcsok ge- 
nerálását végzi, amely a jegyek titkosításához szükséges 
AS (Authentication Service): a fő-fő azonosító szolgál- 
tatás ez, ahol a Kerberos megbizonyosodik arról, hogy 
kik vagyunk. Ekkor kapjuk meg a további jegyek váltá- 
sára feljogosító szuperjegyet, a TGT - t (Ticket Granting 
Ticket), és ez az egyetlen eset, amikor a felhasználó 
jelszavából képzett - valójában a jelszóval, mint kulcs- 
csal titkosított - adatok jelennek meg a hálózaton. 
0 TGS (Ticket Granting Service): A szogáltatásjegyeket ő 
adja ki. A kiadott jegyek a felhasználó azonosítására 
szolgálnak. A jogosultság kiértékeléséhez továbbra is 
Access Token szükséges! 
1. Kiss Pista be szeretne jelentkezni a tartományba. Először 
a saját gépéhez szükséges jegyet igényelnie. A felhasználó 
bejelentkezési igénye eljut az AS-hez, mely a felhasználó 
jelszavával van titkosítva. Ez visszafejthető titkosítás, te- 
hát nem HASH. Az AS elkérheti a címtártól a felhasználó 
jelszavát, s ezzel kibontja a csomagot, így egyértelműen 
megbizonyosodhat arról, hogy Kiss Pista valóban az akinek 
mondja magát (vagy csak tudja valaki a jelszavát). 
2. Az AS jelzi a KDC-nek, hogy újabb kulcsra lesz szükség. 
A KDC az AS-nek visszaküld egy speciális kulcsot. Az AS 
egy olyan jegyet küld vissza a felhasználónak, ami tartal- 
mazza a KDC speciális kulcsát, és a kulcs lejárati idejét, 
ami a KERBEROS belső kulcsával van titkosítva! Ezt TGT- 
nek nevezzük, amit az AS Kiss Pista jelszavával titkosít így 
a TGT biztonságosan utazik a hálózaton. 
3. A felhasználó a TGT-t tárolja, és a benne lévő kulccsal 
kér jegyet a TGS-től, amíg az le nem jár! Lejárata után is- 
mét TGT-t kell igényelnie. 


j 
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A Kerberos azonosítás lépései roppant érdekes és logikus 
lépések láncolatából állnak, amelynek tökéletes megérté- 
séhez egy külön cikk terjedelme is kevés lenne. További ér- 
dekesség, hogy a Kerberos mindenképpen Windows 2000 
Active Directoryt igényel, s ahol ez nincs, ott Kerberos 
sincs (NT4 tartomány nem elég!) , emiatt egy nem várt for- 
dulattal ismét az NTLMv2-vel folytatom a történetet. 


Az NTLMv2 bevezetésének lépései 

Az NTLMv2 segítséget nyújt abban, hogy az azonosítási fo- 

lyamat biztonságosa(bba)n történjen meg, hogy harmadik 

fél jelszólopási esélyét minimálisra csökkentsük. Gyakorla- 
tilag többletköltségtől mentesen (leszámítva a munkaerő 
árát) bevezethető, melynek elvi lépései a következők: 

1. Meg kell határozni a tartomány típusát, amiből is kide- 
rül, hogy hány tartományunk van. Egy tartomány esetén 
nem kell tartanunk a TRUST-ok megszakadásától, míg 
Multi Master típusú tartomány esetén erre figyelnünk kell! 

2. Meg kell vizsgálnunk a felhasználói géppark összetételét. 
Windows9x-es felhasználói gépeken számolni kell a 
DSCLient telepítésével, míg Windows NT 4.0 esetén 
legalább négyes javítócsomagnak kell lennie a gépe- 
ken. Ha ezek a feltételek teljesülnek, jöhet az NTLMv2 
beállítása (WindowsMe-n az NTLMv2-t a cikk írásáig 
nem sikerült életre kelteni). 

3. Először a tartományvezérlőket kell átállítani olyan mó- 
don, hogy az még a LanMan-t és az NTLM - t is egy- 
aránt elfogadja. 

4. Most következnek a munkaállomások! Először az alap- 
feltételnek kell teljesülnie (DSClient; SP4) utána lehet 
az NTLMv2-t beállítani. Konfigurálási hibától óvhatjuk 
meg magunkat, ha az NTLMv2 - t nem kézzel, hanem 
házirend (policy) segítségével konfiguráljuk. 

5. Ha az összes felhasználói számítógép is átállításra került, 
a tartományvezérlőket is átállíthatjuk, hogy innen csak 
az NTLMv2-t fogadják el és utasítsák el a LanMan és 


Hogy készíthetek egy saját Policy-t amivel szabályoz- 
hatom a felhasználói gépek NTLMv2 azonosítását? 
Minden Microsoft operációs rendszer a tartományba való 
bejelentkezéskor házirendfájlt keres. Ennek neve és helye 
operációs rendszertől függ, Windows9x-ek Config.pol fájlt, 
Windows NT alapú rendszerek pedig NTConfig.pol fájlt ke- 
resnek. Egy-egy házirendfájl tartalmának elemeit az úgy- 
nevezett policy template fájlok (ADM fájlok) határozzák 
meg. Az ADM fájlok azt a folyamatot vezérlik, ahogyan a 
munkaállomás módosításokat végez saját regisztrációs 
adatbázisán a bejelentkezési folyamat során (programozás- 
hoz hasonló kódokat tartalmaz) . Nagy előnyük a Policy fáj- 
loknak a Logon Scriptel szemben, hogy a rendszer nevében 
futnak, így gyakorlatilag bármilyen rendszerszintű módosí- 
tás elvégezhető velük. (A Logon Scrpit a bejelentkező fel- 
használó jogosultságait használja. Persze ez megkerülhető, 
de a lehetséges megoldások nem nyújtanak olyan biztonsá- 
got mint a Policy fájlok.) 








Házi feladat 

Készítsünk NTLMv2 Policy-t Windows NT 4.0-ra (és nem 

Windows 9x-re! Ahhoz másik Policy Editor kell, más ADM-et 

kell betölteni és más lesz a fájl neve. Lásd később.) Ennek 

lépései a következők: 

1. Lépjünk be egy Windows NT 4.0 kiszolgálóra, vagy 
munkaállomásra. Indítsuk el a Poledit-et (fent van a 
tartományvezérlőn), vagy készítsünk egy másolatot a 
Windows NT 4.0 Resource Kit-ben találhatóról. Az el- 
indítás után egy üres ablakot látunk magunk előtt. 

2. Töltsük le a példa ADM-t a Netacademia kiszolgálójá- 
ról. (A http://technet.netacademia.net/feladatok cím- 
ről indulva könnyen megtalálhatók a Windows 9x-hez és 
Windows NT-hez készített két különböző ADM fájl). Ha 
ezzel megvagyunk, akkor az üres Poleditben az Options 
menü alatt válasszuk ki a Policy Template...-t. Ekkor 
feljön egy ablak, ahol az ADD gomb megnyomásával ki- 
választhatjuk, hogy melyik ADM-t szeretnénk felhasz- 
nálni a Policy készítéséhez. Ha ezzel elkészültünk, tér- 
jünk vissza az előző szürke ablakhoz. 

3. Már meglevő Policy módosításához a File menüből az 
Open Policy-t, új Policy készítéséhez a New Policy-t 
válasszuk. Az adott gép hirtelen konfigurálásához az 
Open Regitry-t kell választanunk. 

4. A Kkiválasztás után egy Default Computer és egy Default 
User-t láthatunk. Kettőt kattintva valamelyikre, annak tu- 
lajdonságait állíthatjuk. Az NTILMv2 konfigurálásához a re- 
gistry-t kell módosítanunk a HKLM alatt, ez a Default 
Computer-ben végezhető el. Kettőt kattintva a Default 
Computer-re, megjelenik egy új ablak, amiből keressük ki 
az NTLMv2-t. Lenyitva a Change Setting-et aktívvá kell 
tenni (egy pipa jelzi) és ki kell választani a megfelelő szin- 
tet. A módosítás elvégzése után a Policy-t mentsük el! 

5. Az elkészült Policy-t mentsük vissza a NETLOGON 
könyvtárba, majd egy felhasználói munkaállomásról 
lépjünk be a tartományba. A módosításoknak életbe 
kell lépniük. Ezt legegyszerűbben - micsoda véletlen - 
a Policy Editorral ellenőrizhetjük le. Az 1-es és a 2-es 
pontban foglaltakat ismét el kell végeznünk, majd a 
File menü Open Registry-t kell kiválasztanunk. Ezek 
után az NTLMv2-t kell lenyitnunk és ellenőriznünk, 
hogy a módosítások életbe léptek-e. Amennyiben nem, 
el kell kezdenünk a hibakeresést. 

Windows 9x-re alkalmas Policy fájlt is készíthetünk a fen- 

ti lépéseket követve, annyi különbséggel, hogy a lépéseket 

Windows9x-es gépen a hozzá tartozó Poledit-tel kell elvé- 

geznünk és a Policy fájl neve Config.pol kell, hogy legyen. 
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NTLMv2 konfigurálása Policy-ból 


És végül 

EL szeretném mondani, hogy a hálózatok az alapvető szabá- 
lyokat betartva, biztonságosak. A Windows NT 4.0 és a Win- 
dows 2000-es hálózatok biztonságához kétség sem férhet, ha 
az jól karban van tartva, megfelelő személyzet üzemelteti! 
Egy hálózat biztonságához sokat ad a jó tervezés, a hibátlan 
üzemeltetés és a megfelelő eszközök. Ezek a Microsoft operá- 
ciós rendszereiben megtalálhatók, használhatók és elérhetők! 


Harmath Zoltán, MCSE MCPx-i 
zolee(ogeniusgroup.hu 


Utószó 

Ez a cikk nem jöhetett volna létre, ha Zoltán nem szán né- 

hány emberévet életéből az NTLMv2 megismerésére és bein- 

dítására, ugyanis míg az elvi lehetőség régóta adott volt, az 

NTLMv2 nem működött Windows 9x-en a gyári leírásban és 

egyéb helyeken fellelhető beállításokkal. Ebből két következ- 

tetés vonható le: 

1. Vagy senki nem használta, mi több, ki sem próbálta e le- 
hetőséget előtte e földön. 

2. Vagy senki az égvilágon nem ellenőrizte le, és nem vet- 
te észre, hogy AZ és ÚGY, ahogyan meg van írva, nem 
működik. 

Bármelyik állítás az igaz, , kollektíven" szégyelljük magun- 

kat, és használjuk az általa összebarkácsolt ADM-eket. 

(Lapzárta után érkezett a hír, hogy végre Redmond is kap- 

csolt, és új Knowledge Base cikket eresztett meg, mely már 

helyesen tartalmazza a beállítás menetét.) 
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DNS checklist 

Kicsit rendhagyó módon indul e havi dupla KV-nk. E hónap- 
ban egy olyan témával kezdjük, mely havonta négyszer-ötször 
fel szokott bukkanni a NetAcademia levelezési listán. Eleinte 
lelkesen válaszolgattunk, a múlt héten azonban már csak 
ennyit írtam lustán a kérdezőnek: DNS. 


Az alább felsorolt kérdések mindegyike így kezdődik: Windows 
2000 Active Directory telepítése után... 


K1: ... a Windows 2000 Professional számítógépek egyáltalán 
nem, vagy csiga lassan jelentkeznek be a tartományba. 

K2: ... Az Active Directory Users and Computers néha azt üze- 
ni, hogy nincs meg a domain, miközben nyilván megvan, mert 
éppen azon dolgozom. 

K3: ... a tartományvezérlő nem látja az Internetet. Ja, a töb- 
bi gép sem. 

K4: ... szeretnék még egy DC-t telepíteni, de a telepítési va- 
rázsló (DCPORMO.EXE) azt írja, hogy a tartomány nem talál- 
- ható. Ez nem igaz, itt van fél méterre tőlem. 

K5: ... szeretnék még egy DC-t telepíteni, de állandóan Acces 
Denied üzenetet kapok, pedig már szinte az Atyaúristen cso- 
portba is behelyeztem magam. 

K6: ... a két tartományvezérlő több napja nem látja egymást, 
és nem történik meg a replikáció. Az egyik DC-n felvett fel- 
használó egyszerűen nem jelenik meg a másikon. 


V: DNS 

Ennyit írtam, ez azóta is a lista legnagyobb információsűrűsé- 
gű válasza, s ezzel elintézettnek is vettem az ügyet, de L. Zs. 
barátom, aki éppen talán K2-vel vívott több napos küzdelmet, 
további kérdésekkel bombázott: 

Mondjam meg, mikor indul a legközelebbi DNS tanfolyam. 
(Nincs ilyen tanfolyam) 

Vagy mutassak neki egy jó magyar nyelvű könyvet a DNS-ről: 
(Nincs) 

Akkor menjek a fenébe :-) 

A teljes szomorú igazság az, hogy ez utóbbi levélváltás már nem 
a lista színe előtt zajlott, s a probléma megoldása sem került fel 
oda. Az alábbiakban felsorolok néhány KV-t, melyek remélem 
segítenek a mindenütt felbukkanó DNS problémák gyors megol- 
dásában, bár nem pótolják a DNS alapos megtanulását Ez utób- 
biban segít az ezen lapszámban elindított DNS cikksorozat. 


K: Megy-e az Active Directory DNS kiszolgáló nélkül? 
V: Alig. Menni megy, de telesírja bánatában az Eseménynaplót. 


K: Miért? 

V: Mert a Windows 2000 tartományok tökéletesen egybeesnek 
a DNS tartományokkal, és az elavult WINS helyett mind a tar- 
tományvezérlők, mind pedig a 2000-es munkaállomások DNS 
lekérdezéssel keresik meg a hálózat erőforrásait. Ha nincs 
DNS, akkor bizonyos szolgáltatásoknak lőttek. Nincs például 
Kerberos bejelentkezés, hogy csak egyet említsek a sok közül. 


K: Muszáj-e Microsoft DNS Servert használni? 
V: Egyáltalán nem. Minden olyan DNS Server megfelel, amely le- 
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hetővé teszi SRV rekordok felvételét. Ez az egyetlen kö- 
vetelmény. A közhiedelemmel ellentétben nem szük- 
ségszerű dinamikus DNS-t használni. Ha nem DDNS 
kiszolgálónk van, az sem tragédia. Az AD telepítő 
varázsló ugyanis az összes szükséges DNS rekord- 
kupacot beleírja egy NETLOGON.DNS nevű, Bind 
kompatibilis zónafájlba, amit akár kézzel is beter- 
melhetünk - bár a DDNS sokkal kényelmesebb. 





K: Ha feltelepítem a DC-re a DNS Server-t, akkor 

már mehet is a DCPROMO? 

V: Nem. Attól még, hogy felkerült, nem változik meg automa- 
tikusan a gép TCP/IP beállítása, így hiába van ott, ugyanazon 
a gépen a DNS Server, a masina továbbra is a korábban beál- 
lított DNS Server-t fogja használni. Ha ez az Internetszolgál- 
tatód, akkor a DCPROMO dinamikus DNS bejegyzési kérelmei 
OTT KINN fognak megjelenni (és eldobódni) , a telepített DNS 
szervered meg üres marad!!! Erről a szomorú tényről Network 
Monitorral lehet meggyőződni. 


K: Miért van az, hogy amelyik munkaállomás tud Interne- 
tezni, az nem látja az Active Directory-t, és vica versa? 
V1: Látod a netet, de nem látod az AD-t? Mert ha a gépen 
nem a belső DNS Server van beállítva a TCP/IP paraméterek 
között, akkor nyilván nem fogják megtalálni a szükséges erő- 
forrásrekordokat, hisz az Internetszolgáltatónk DNS Server-e 
nem fog tudni a mi belső AD telepítésünkről. 

V2: Látod az AD-t, de nem látod a netet? Olvass tovább, a bel- 
ső DNS Server-rel lesz még tennivalód. 


K: Bele lehet-e ugrani a DCPROMO-ba telepített DNS 
Server nélkül? 

V: Bele. Ha majd azt kérdi, csináljon-e neked egyet, mondj 
YES-t. (Ez ugyan root DNS-t telepít, de sebaj. Olvass tovább) 


K: Ha már rég fent van a DNS, és a megfelelő zóna is ott 
van, miért nem jegyzi be magát a nyavalyás? 

V: Mert le merem fogadni, hogy a zónán nem engedélyezted 
a dinamikus frissítést. Jobbklatty, properties, Allow Dynamic 
Update, Yes, Ok. 
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K: De engedélyeztem, és mégsem ír bele 

V1: Mert elgépelted a tartományod nevét (hogy ez milyen 
gyakori! Legalább tíz esetet láttam, ahol a jól felkészített fa- 
latraksz.hu zónába az Istennek sem kerültek be a falatrax.- 
hu tartomány bejegyzései :-) 

V2: Mert türelmetlen vagy. Az újraboot után jó néhány perc, 
mire megjelenek az SRV rekordok. Ha unod a várakozást 

NET STOP NETLOGON 

NET START NETLOGON 


K: Az igaz, hogy elsőre elbaltáztam, de most már tele a zóna, 
ennek ellenére minden hibajelenség ugyanúgy fennáll. Meg- 
őrülök! 

V1: Vár még tíz percet, és minden hirtelen megjavul! :-O 
V2: Hát igen. Ez - hogy is mondjam nyomdafestéket tűrő mó- 
don - baj. Ugye hiába bújod a Tech.Net CD-t, semmi válasz? 
Hát tudd meg, itt összeesküvés van. A TCP/IP stack újításai 
közül a legzavaróbb a minden 2000 gépen jelen lévő DNS 
gyorsítótár (cache), mely az egyszer már begyűjtött DNS re- 
kordokat betárazza, hogy legközelebb ne kelljen ugyanazért a 
rekordért felkeresni a DNS Server-t. Ám a cache úgynevezett 
negatív bejegyzéseket, tehát válaszhiányokat is tárol, így hi- 
ába javul ki a zóna, még 5-10 percig a régi semmi van a gyor- 
sítótárban. Tekintsd meg: 

IPCONFIG /DISPLAYDNS 

Majd irtsd ki: 

IPCONFIG /FLUSHDNS 

és már megy is minden, mint a karikacsapás! 


K: Miért nem látjuk az Internetet? Eddig olyan szépen ment! 
V: Mert a DNS szervered, amelyre minden ügyfél mutat, nem 
lát ki, hisz senki sem mondta meg neki, merre keressen to- 
vább, ha egy kérdésre nem tudja a választ. Be kell állítunk 
úgynevezett forwarder DNS Server-t, ezzel minden ismeretlen 
kérést átirányítunk például az Internetszolgáltatónkhoz. 
Jobbklatty a DNS Server-en, Properties, Forwarders fül. 


HZE s 22 
ji 1 Monitoring ] Security 
Interfáces Forwarders — ] Advanced] FiootHints 
Forwardets help resolve any DNS gueries not answered by this servet. 

Fr Ereiizfomsdet 
To add a forwarder, type its IP address, and then cíck Add. 
IR address: 


[0 . . . HENK 
Bemove I 
Up ] 
Dawn 


Forward time-out (seconds) 


F— 


TT Dopotuse recursion 





fox JI tea [/ és] 


K: Ott vagyok éppen, de mind a Forwarders, mind a 
Root hints fülön szürke minden beviteli mező. Most 
mindennek vége? 

V: Nem, dehogy. Most kezdődik a tánc! Az a baj, hogy - vé- 
letlenül vagy szándékosan - root DNS-t sikerült telepíteni. Be- 
széljük le a DNS szerverünket a Root Name Server szerepről! 
Menj vissza a zónákhoz, állj rá a . (pont) nevűre, és töröld le. 
(Ne kérdezd miért, csak tedd amit mondok.) Most nyomj F5- 
öt. Na most menj vissza a Forwarder beállításra. Mellesleg a 
Root Hints is magától feltöltődött! 


Hát hirtelen ennyi, és akkor hol van még a zónadelegáció, az 
NS, MX és ki tudja még milyen rekordok! Mindenkinek mele- 
gen ajánlom DNS cikksorozatunkat! És most következzen a 
szokásos tallózás a NetAcademia nyilvános levelezési listáinak 


forgalmából. (Feliratkozás: http://lyris.netacademia.net) 


K: Sajnálattal tapasztaltuk, hogy az SOL Server 6.5-ös a 
tárolt eljárásokat TÁROLT ELJÁRÁSKÉNT meghívva 
HOSSZABB idő alatt futtatja le, mintha egyszerű sgl 
scriptként futtatnánk ugyanazt. Emiatt fejlesztés és 
tesztelés közben egy kb. 200 - 250 ezer rekordot érintő 
szűrés 1,5 perc alatt futott végig scriptként, ám tárolt 
eljárásban a válaszidő 5 és 7 perc között volt. Sajnos a 
tárolt eljáráson már nem lehet egyszerűsíteni, mert az 
már a használhatóságát vonná kétségbe (indexek van- 
nak, és az algoritmus kötelezően bonyolult) . Érdekes mó- 
don SOL7-es alatt a lekérdezés ugyanezen tábláknál 
ugyanekkora adatbázisban a kétféle módszerrel egyfor- 
mán 35 másodperc alatt futott végig. De sajnos nem az 
a feladat, hogy SOL7-esre térjünk át. Mit tegyek? 


V: Van egy jó meg egy rossz hírem, s a kettő ugyanaz: térj át 
SOL Server 7.0-ra, vagy méginkább 2000-re. A dolog magya- 
rázata az SOL Server 6.5 és 7.0 memóriakezelése, lekérdezés 
optimalizálója, joinstratégiái, egyszóval belső felépítése kö- 
zötti különbségekben rejlik. Lehet ugyan játszadozni a tárolt 
eljárás meghívásakor a WITH RECOMPILE opcióval, amely 
minden alkalommal új végrehajtási tervet készíttet a lekérde- 
zéshez, de az eredmény több mint kétséges. Az SOL Server 6.5 
sohasem volt képes dobogós helyet elfoglalni a független 
szakértők által zsűrizett teljesítménytesztekben (http:// 
www.tpc.org), míg a 7.0 verzió már béta korában megtette 
ezt. Fontos tudni, hogy az SOL Server 2000 egyenesen áll a 
képzeletbeli dobogó legfelső fokán, mi több, lassan az első öt 
helyen SOL 2000-t fogunk találni. 

Forrás: NetAcademia SOL lista 


K: Vállalatunknál az előző, azóta elment rendszergazda 
telepítette az Exchange Server 5.5-öt mégpedig sajnos 
úgy, hogy az Administrator lett a Site Service Account. 
Ha most megpróbálom megváltoztatni az Admin jelsza- 
vát, akkor a következő alkalommal nem indul el az Ex- 
change. Később észrevettem, hogy az Exchange Admin 
programmal , után lehet húzni" a jelszót, de ez akkor is 
kényelmetlen. Nem lehetne lebeszélni az Exchanget ar- 
ról, hogy így jelentkezzen be? 








V: De. Control Panel-sServices. A megjelenő listában minden 
egyes ,Microsoft Exchange..." kezdetű szolgáltatáson a 
StartUp nyomógomb mögött meg lehet változtatni azt a fel- 
használói fiókot, amivel a szolgáltatás fut. Persze előtte az új 
Servicce felhasználónak adni kel egynémely jogot: az NT-ben 
hog on as a Service", Act as part of the op. System" és 
Backup Files and Directories", míg az Exchange-ben minden 
szinten (Organization, Site, Configuration) ,Service Account 
Admin" szerepet kell adni (majd az Organization szintjén el 
kell venni tőle a Search jogot a ServAcctAdmin szerephez ké- 
pest, ha előtte sem volt beállítva) . Talán mégis könnyebb lett 
volna eleve jól telepíteni :-) 

Forrás: NetAcademia Exchange lista 


K: Létezik az Active Directoryhoz valami könnyen hasz- 

nálható ÉS ingyenes elemzőprogram? 

V: A http://www.netig.com/adcheck/ címről letölthető 

eléggé egyedi felhasználói felületű (olyan, mint egy PDA) 

NetIO ADcheck termék a megfelelő eszköz az Active Direc- 
" tory vizsgálatára. 

A következő tesztek hajthatók végre a segítségével: 

"? Hálózati kapcsolat, és egyéb beállítások helyessége 

"0 Tartományvezérlők listázása, működésük elemzése 

2 FSMO szerepek listázása 

2 Egyes tartományvezérlők közötti replikáció sikeressége 

0 A replikáció aktuális állapota (mely gépek vannak 

lemaradva, és mennyivel) 
A tesztek eredményét pedig a nagy Details feliratú gomb meg- 
nyomása után HTML-ben kapjuk! 





K: Az lenne a feladatom, hogy sok száz gépen állítsak be 
azonos NTFS jogokat. Ezt egyszer még könnyű végigkat- 
tintgatni, de nem lehetne erre valahogy egy batch fájlt ké- 
szíteni, azaz parancssorból állítani az NTFS jogosultságait? 
V: A Windows NT/2000 része a CACLS.EXE parancssori segéd- 
program, mellyel a feladat könnyen elvégezhető. Majdnem 
mindent tud, például a Windows 2000 verzió már arra is ké- 
pes, hogy ne egyszerűen felülírja a jogosultságlistát, hanem 
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Show DC Status 







Test name 


Machine name PLATAN 

Domain name netacademia fm 

Date Tue Oct 17 15:08:56 2000 
Elapsed time (in ms) Oms 


Description 
This test provides information about the replication status of a domain 
controller. VVhen you select this test, ADcheck performs several actions: 


1. Atperiodic intervals, Active Directory automatically adjusts the 
replication topology of your network (this process is known as the 
Knowledoe Consistencv Checker). ADcheck scans the Knowedce a 
[Ed00ne f (MEM computer 4 
beleszerkesszen. Ezzel az ingyenes változattal azonban csak a 
szokásos jogosultságok beállítása valósítható meg, azaz Read, 
Write, Change (write) és Full control állítható be. Ha ennél is 
finomabban kell állítani a jogosultságokat, akkor a Windows 
2000 Resource Kiten található XCACLS.EXE-re lesz szükség, 
amely sokkal finomabban hangolhatóvá teszi a jogosultságál- 
lítást, hisz az előbbieken túl Change Permissions, Take Owner- 
ship, Execute, egyedi Read, Write, Delete és üres (!) ACE is ál- 
lítható vele. Természetesen VBScript is írható, külső gyártók 
szoftverei is használhatók, de az XCACLS.EXE funkcióinál alig- 
ha lesz szükség többre. 
Forrás: NetAcademia Windows 2000 lista 





K: Azt szeretném elérni, hogy az Encrypting File Sy- 
stem titkosítás egy egérkattintásnyi közelségbe kerül- 
jön a felhasználókhoz, ne kelljen állandóan a Proper- 
ties-sAdvanced ablakba beszaladni, valahányszor tit- 
kosítani akarok valamit. 

V: A Windows 2000 Beta 3 még tartalmazott EFS menüpontot 
a fájlok gyorsmenüjében, ám a végleges változatból ezt sajnos 
kivették. Visszacsempészni a következő módon lehet: a 
HKLMISoftwarelMicrosoftWWindows) 
CurrentVersionlExplorerMadvanced 

kulcs alá fel kell venni a 

EncryptionContextMenu-1 (REG DWORD) 
Értéket, ekkor újraindítás után megjelenik a gyorsmenüben az 
Encrypt/Decrypt! 


Forrás: NetAcademia Security lista 














X 


Az októberi különszámunkban megjelent SOL an- 
notált sémák késztettek e cikk megírására. A 
visszajelzések alapján ugyanis világossá vált 
számunkra, hogy égető szükség lenne egy tu- 
dományos fantasztikumtól mentes, kizárólag 
értelmes szavakat tartalmazó XML cikk meg- 
jelentetésére, mert amíg valaki meg nem írja 
élete első XML/XSL dokumentumpárosát, ad- 
dig bizony nehezen éli bele magát a bonyolul- 
tabbnál bonyolultabb XML alkalmazások (például 
BizTalk Server) lelkivilágába. Azután itt vannak a 
szokásos kérdések: az XML az egy új programozási nyelv? 
Nem. Új adatbázis-formátum? Nem-nem! 


A teljesség igénye nélkül 

Félre hát az SGML-lel és az URN-ekkel, készítsünk hirtelen 
olyan XML dokumentumot, amely nem több mint három sor 
- készítsük el a , Hello World!" alkalmazást XML-ben! Elő a 
Nisual" Notepaddel! 


Z£gyoker2 
cxcdumarxHello World!c/duma: 
€/gyoker2 


Ennyi. Save. Legyen HELLO.XML a neve. Nyissuk meg Inter- 
net Explorerrel. Hát nem gyönyörű? Ha Internet Explorer 5- 
össel nézzük, akkor valami hasonlót kell látnunk: 
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- egyokers 
zdumaszHello World! c/dumaz 
c/gyoker: 
él 
[E1 Done [I [69 internet 4 


Korábbi böngésző használata esetén nem tudom, mi jelenik 
meg :) Aki ki szeretné próbálni a cikk további példáit, hasz- 
nálja fel a képernyőképekről leolvasható URL-eket, hisz a 
fájlok az újság weblapján is elérhetők. (Az egyszerűség és 
olvashatóság kedvéért az összes XML példám ékezetmentes, 
mert UTF-8 kódolással kellett volna a Notepaddel elmente- 
nem a fájlokat, amire a Notepad képes ugyan, de kerülni pró- 
báltam a konfliktushelyzeteket. ) 

De mit is csináltunk? Látható, hogy XML kódocskánk na- 
gyon hasonlít a HTML nyelvre, ugyanúgy ctags-ekkel (ma- 
gyarul: HTML tagok) dolgozunk, mint hagyományos weblap- 
készítés közben. A drámai különbség az, hogy kinek szólnak 
e tagok: tisztán látszik, hogy nem a böngészőnek (nem, 
nem azért lett piros!), hisz érintetlenül megjelentek a ké- 
pernyőn. Honnan is tudná az Explorer, miként kell formáz- 
ni a cdumas tagot? Az XML fájlban a tagok nem az adatok 
megjelenítését vezérlik, hanem a végfelhasználónak (em- 
bernek vagy gépnek) nyújtanak információt a tartalom logi- 
kájáról. Valaha a HTML nyelv is ügyelt erre, hisz nem for- 
mázó, hanem tartalmi leírótag például a ctitlez, ám az évek 
folyamán az egyre giccsesebb weblapok megjelenésével ez 
a vonulat elsorvadt. Hajdanában a ctitlez tagot valóban a 
dokumentum címével illett feltölteni, hogy a keresőprogra- 
moknak könnyebb dolguk legyen, ám mivel ez jelenik meg 
az ablak tetején a böngésző címsorában, mi sem kézenfek- 


ezdetnek nem rossz! 





vőbb, minthogy ideírjuk marketingakcióink időpontjait. 

Az XML azonban visszahozza a dokumentumokba a tartalmi 
leírást, a metaadatokat. Egy XML dokumentumban sohasem 
találunk közvetlen megjelenítési, formázási információt, vagy 
ha igen, az baj. Az XML fájl legyen adat központú, hisz soha- 
sem tudhatjuk, hogy mi a végső célja: ha bankkártya adatokat 
cipel két vállalat között (született az SAP-ben, majd a BizTalk 
Serveren átvonulva elnyeli az SOL Server 2000) , akkor belátha- 
tó, hogy a külalaki információk tökéletesen feleslegesek! Más 
a helyzet, ha böngészőben meg kell jeleníteni. Ilyenkor segí- 
tenek a stíluslapok, az XSL fájlok - de erről majd később. 
Most térjünk vissza az XML-hez, és vizsgáljuk meg, mitől 
több ez, mint spanyol viasz. 


Kiterjeszthető 
XML-eXtensible Markup Language. Bármit le lehet írni vele. 
Ime a kedvenc Billjeim: 


g£gyoker5 
Sbill:Bill Clintonc/bill: 
dcbill:Bill Gatesc/bill: 
dcbill:Billy Idolc/bill: 
dcbill:Buffalo Billc/bill: 
£/gyoker2 


Ha jellemezni kellene őket, ugyanúgy paramétereket adha- 
tok nekik, mint például HTML-ben egy betűtípusnak. Ha- 
sonlítsuk össze ezt: 


cfont facer"arial" sizez"2" 
color-"red"5Hello World!c/font: 


ezzel: 
dcbill munkahelye-"Fehér Ház" kora—"44" 
biztos ez-"nem"5Bill Clintonc/bill: 


Hierarchikus 

Vegyünk egy a valós életből ellesett, szigorúan hierarchikus 
példát! Írjuk le egy autó összes ülésének, támlájának, hu- 
zatának mintáit egyetlen fájlban! 

A hierarcikus jelleg olyan esetekben igazán hasznos, amikor 
például egy összetett, apa-fiú adatbázis-lekérdezés eredmé- 
nyét kell eljuttatni egy munkaállomásra. 


A http://technet.netacademia.net/feladatok/auto.xmi s Pálé 
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- egyokers 
- gautos 
Trabant 
- gules tamlaz"dontheto": 
Vezetoi 
- chuzat: 
karikas 
cminta51. karikac/mintaz 
caminta:2. karikac/mintaz 
c/huzats 
£/ulesz 
cules tamla-"dontheto"s5Anyosc/ulesz 
- ules tamla-"kenyelmetlen": 
Jobb hatso 
FE 
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Az XML előtti világban ez csak több, táblázatos lekérdezés 
egymás utáni átvitelével volt lehetséges. (Illetve szabvány- 
mentes módon egy-két gyártó megvalósította ugyan, de pi- 
aci sikert senki nem ért el vele. ) 


Szabványos 

Ennek fontosságát azt hiszem, nem kell ecsetelnem. Vég- 
re mindenfajta konverzió nélkül szót ért egymással SOL 
Server és Oracle, Exchange Server és majd a konkurensek 
is, ha végre észbe kapnak. 


Szigorú 
A szigorúság alatt azt értem, hogy az XML szintaktikája 
sokkal kötöttebb, mint hinnénk, és ez többnyire jót tesz 
neki. Amitől viszont minden Windowshoz szokott XML gu- 
ru el fog hűlni: megkülönbözteti a kis- és nagybetűket 
(case sensitive). A ctagz-nak nem bezárója a c/Tags :-( 
Úgy tűnik egy nagyhangú junixos is helyet kapott a szab- 
ványtestületben. Viszont igen lényeges szigorítás, hogy 
minden tagot minden körülmények között be kell zárni, 
még akkor is, ha nincs értéke. A HTML-ben simán elhelyez- 
" hetünk lezárás nélkül egy önálló cBR: (sortörés) tagot, 
XML-ben viszont ennek így kell kinéznie: 


LZönlezárás/2 


Olvasható 

Végre itt a világ legjobban debuggolható formátuma! Az 
XML fájl ugyanis értelmes TXT, olvasható! Mindenféle se- 
gédeszköz nélkül tudunk benne hibát keresni. A formátum 
nyilván csak egy adott befogadható adatmennyiségig élve- 
zetes olvasmány, de hibakeresésre tetszőleges szövegszer- 
kesztő használható. Ugyanakkor e szószátyárság miatt jó 
nagy is, ám pont emiatt... 


Remekül tömöríthető 
Persze, hisz a redundancia foka közel végtelen amikor már 
egymilliomodszor ismételjük el a fájlban a tag nevét: 


Z£gyoker2 

gXpizza hus-"nincs" 
sok"5:Margareta 
£/pizzaz 

£gpizza hus-"hatfele" zoldseg-"brokko- 
li":Ouattro Staggioni 

£/pizza: 

£/gyoker2 


sajt-"jo 
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- egyokers 

pizza husz"nincs" sajt-"jo 
sok"-Margaretac/pizzaz 

pizza husz"hatfele" 
zoldseg-"brokkoli"-guattro 
Staggionic/pizzaz 

cpizza husz"kolbasz" 
zoldseg-"nincs"-Bolognesec/pizzaz 

pizza husz"nincs" 
zoldseg-"ananasz":Hawaiic/pizzas 

pizza hus-"halacskak, rakok" 


naldozaztanm nős Tertot A tönen ,/oiszas 
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Megjelenítés XSL stíluslapokkal 

Evezzünk vadabb vizekre! Próbáljuk Internet Explorerben 
csinosan megjeleníteni az adatokat! Ehhez az XML fájl mel- 
lett szükségünk lesz egy másik fájlra is, mely a megjelení- 
tési információkat hordozza - ez az XSL. Ha az XSL-t való- 
ban megjelenítésre használjuk (miért, mire lehet még...?) 
akkor belső szerkezete HTML jellegű. Képzeljük el úgy, 
mint egy mintát, melyet az XML adattartalmával kell kitöl- 
teni. Ha az XML-ben 1000 féle pizza van, amelyet egy 
HTML táblázatban szeretnénk látni, akkor az XSL tartalma 
logikailag a következő: 


cXchtml: 
ctable2z 
Ezt ismételd meg annyiszor, 
pizza van: 

£tr2 
Zxtd:Na ide jöhetnek a pizzanevekc/td2 
ctdo:Ide pedig a sajtosság fokac/td: 

ctdöstb....€/td: 


ahány 


£/tr2 
ciklus vége 
£€/table: 
£€/html: 


Az igazsághoz hozzátartozik, hogy ez a fajta procedurális 
megközelítés csak az egyik, mégpedig a primitívebb XSL 
megjelenítési lehetőség, mely kizárólag well-known, azaz 
jól ismert struktúrájú adathalmazon használható. Amennyi- 
ben sánta fa és egyéb érdekfeszítő adathalmaz feldolgozá- 
sára volna szükség (lásd később), akkor elő kell(ene) ven- 
nünk halmazszemléletű XSL tudásunkat... 

Térjünk vissza mindkét lábunkkal a földre, és fejezzük be az 
előbbi XSL-t úgy, hogy az előbb ékes magyar nyelven beir- 
kált utasításokat lefordítjuk XSL transzformációs tagokra: 


Ezt ismételd meg annyiszor, ahány piz- 
za van 


ciklus vége 


helyett 
£xs1l:for-each select-"gyoker/pizza"5 


£/xs1l:for-each2 
Na ide jöhetnek a pizzanevek 


helyett 
£xsl:value-of /5 (Önlezáró.) 


A Ccpizza: tagok belső attribútumait 
(hus, zoldseg) pedig a következőképpen 
írathatjuk ki: 


£xs1l:value-of select-—"€hus"/5 
£Xxs1l:value-of select-"€zoldseg"/5 


ahol a kukac karakter jelzi, hogy itt nem egy érték, hanem 
egy attribútum tartalmára vagyok kíváncsi. Végül lássuk el 
a fájlt a hagyományos XSL fejléccel, 





DEvELPOER / XML 


La?xml version—"1.0"?5 
£Xxs1l:stylesheet 
xmlns : xs1—"http: //www.w3 .org/TR/WD-xs1"5 


melyet megérteni nem kell, csak flopin a zsebünkben hor- 
dani, hogy ha hirtelen kellene XSL-t alkotnunk, ne álljunk 
bután és tehetetlenül a probléma megoldásának utolsó 
mozzanata előtt. Megfigyelhető, hogy az XSL fájl is XML 
nyelven íródott, csak egyfajta szabályos, rögzített szinta- 
xisú XML-lel van dolgunk. 

Apropó flopi: mentsük rá azt a sort is, amelyik az XLM-XSL 
összerendelést végzi - az sem triviális! 


c?xml version—"1.07?5 
2X?xml-stylesheet type-"text/xsl" 
href-"pizza.xs1l"?5 


Az XSL végleges formában: 


L?xml version-"1.0!"?5 
€Xxsl:stylesheet xmlns:xs1l- 
"http: //www.w3 .org/TR/WD-xs1"5 
Xxsl:template match-"/"5 
LxHTML2 
LxBODY2 
LTABLE BORDER-"2"5 
LTR2 
LxTD:Pizza nevec/TD2 
LTDPHusS/TD2 
LxTD3Zoldsegc/TD: 
£/TR2 
£xs1l:for-each select-"gyoker/pizza": 
LxTR2 
LxTD2Xxsl:value-of /2€/TD2 
LxaTD:XCxsl:value-of 
select-"€hus"/5c/TD2 
LxaTD2Xxsl:value-of select-—"(€zold- 
seg"/5c€/TD2: 
£/TR2 
£/xs1:for-each: 
£/TABLE2 
£/BODY5 
£/HTML2 
£/xs1:templates 
£/xs1l:stylesheet2 


Az XML ezek után így jelenik meg: 


A http://technet.netacademia.net/feladatok /pizzati 
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nincs 











Pizza neve 
IMargareta 
Ouattro Staggioni hhatfele 
kolbasz [nincs 
nincs jananasz 


halacskak, rakok [repa 


IZoldseg 





brokkoli 








Bolognese 
[Hawaii 
Frutti di Mare 

















Hogy az alapokból semmi se maradjon ki, most készítsünk 
halmazszemléletű XSL megoldást is, ehhez azonban először 
szükségünk lesz egy táblázatba nem foglalható, masszívan 
hierarchikus XML adathalmazra: 


£gyoker2 
LIxmozisMuvesz 
Ixterem:xChaplin 
cfilmsxMatrix 
XKkezdet:14:00 
£/kezdet2 
dXxkezdet:316:00 
£/kezdet2 
c/film: 
cfilm:Forrest Gump 
dXxkezdet:17:00 
€/kezdet: 
c€/film: 
£/terem: 
ZteremxHuszarik 
cfilmo:Mumia 
IXkezdet523:59 
£/kezdet: 
€/film- 
£/terem2 
£/mozis 
amozisKobanya 


cfilm:Rain Man 
Zkezdet5317:00 


€/kezdet: 
ckezdet:18:30 
£/kezdet: 
c/film: 
Sszakkor:Vasutmodellezes 
cXcnap:Szombat 
£/nap2 
cXxckezdet2313:00 
£/kezdet2: 
£/szakkor2 
£/mozis 
£/gyoker2 


Könnyen belátható, hogy ez a struktúra kényelmesen nem 
jeleníthető meg kétdimenziós táblázatban, hisz a Művész 
mozi esetén mozi-sterem--film-skezdet egymásba ágya- 
zást láthatunk, míg a Kőbánya esetén a terem megkülön- 
böztetésének nincs értelme, továbbá ott nemcsak filmeket 
vetítenek, hanem szakkörök is vannak - egyébként tavaly 
bezárt :( . A leghelyesebb az lenne, ha nem is kellene cik- 
likusan végigfutkározni a sorokon, és rákeresni, hogy va- 
jon éppen miféle adat került elénk, hanem a formázást a 
lehető legteljesebb mértékben rábízhatnánk az XSL értel- 
mezőre. Ennek semmi akadálya. Az XSL képes arra, hogy az 
általunk definiált formátummintákat automatikusan, cikli- 
kusan, rekurzíve stb. ,ráfesse" az adatokra. Nem kell mást 
tennünk, mint úgynevezett templateket definiálnunk, 
hogy hogyan is nézzen ki egy filmcím, legyen az bármilyen 
mélyen is a hierarchiában, 


£Xxsl:template match-"film"5 

Zfont  color-"green"5C€xsl:apply- 
templates/52c/font: 
£/xsl:templates 





azaz a filmcím legyen zöld. Az xsl:apply-templates arra 
szólítja fel az XSL értelmezőt, hogy ezen a ponton vesse 
bele magát az XML fáljba, és keresse ki az adatokat. Érde- 
mes megjegyezni, hogy az xsl:apply-templates rekurzív hí- 
vás, azaz ha az előásott adatoknak gyermekadataik vannak 
(itt a filmeknek kezdetük van) akkor azokra ismét megad- 
hatunk templatet, valahogy így: 


£Xxs1l:template match-"kezdet"5 
Zb:Cxsl:apply-templates/2c/b: 
£/xs1l:templatez 


A kezdet félkövér lesz. Itt azonban két esetet meg kell kü- 
lönböztetnünk: ha a kezdet egy film gyermeke, akkor a re- 
kurzív hívás miatt cxsl:apply-templatesz örökli a szülő for- 
mátumát is, emiatt nemcsak félkövér, hanem zöld is lesz. 
Ha a kezdet nem filmhez tartozik, hanem például egy szak- 
körhöz, akkor fejlesztésünk jelen stádiumában nincs mit 
örökölnie a szülőjétől (mert arra még nem írtunk megjele- 
nítési mintát), ezért egyszerűen félkövér lesz. Írjunk min- 
tát a szakkörre is: 


£xsl:template match-"szakkor"5 


cfont color-"red"5cCxs1l:value- 
0£/2£/font2 
£/xs1l:templatez 


Vajon ettől pirossá válik-e a szakkör alatti kezdete tag ki- 
jelzése is? Igen, mert az cxsl:value-ofz nemcsak az adott 
tag értékét írja ki az adott mintával, hanem a gyermeke- 
két is. Ez néha súlyos bonyodalmak forrása lehet, mert ha 
tényleg csak az adott szint értékét kérjük, azt másképp, 
XSL függvénnyel kell megadni, így:  cxsl:value-of 
select-"text()"/2. Ez leállítja a rekurziót. Végül hadd mu- 
tassam meg a dzsoli dzsóker mintát, amely szintén az előb- 
bi text() függvény használatával minden egyes további, 
mintával el nem látott, illetve , mintás", de cxsl:value-ofs 
taggal ki nem íratott értéket egyszerűen a meghívás he- 
lyén (rekurzióról van szó!) kidobál a kimenetre: 


£xsl:template match-"text()"5 
cxsl:value-of/5 
£€/xsl:templates 
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Ez a minta minden halmazszemléletű XSL fájban legyen 
benn, hogy tehesse azt, amire való: jelenítse meg a kifelej- 
tett, félredefiniált halmazok adatait is. Természetesen itt is 
használhatunk HTML formázást, de vigyázzunk: minden fent 
említett elemre hatással lesz ez a minta! 
És már majdnem készen is vagyunk, még kell egy globális temp- 
late az egész folyamat beindításához (match-"/") és save. 
A mozi.xsl egy kicsit túl nagy ahhoz, hogy ide illesszem, 
ezért letölthetővé tettem. A cikkben előfordult összes XML 
és XSL fájl letölthető a következő címről: 

8 i k/xml.zi 


A ,formázott" dokumentum pedig így néz ki: 


AA http://technet.netacademia.net/feladatok/mozi 2.Xml. 
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Muvesz Chaplin Matrsz 14:00 16:00 Forrest Gump 17:00 Huszarik 
Mumia 23:59 
Kobanya Rain Man 17:00 18:30 Vasutmodellezes Szombat 1300 
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A zip remek lehetőséget nyújt arra, hogy példáimat ki-ki 
ízlése szerint átirkálja, próbálkozzon vele. A további tanu- 
lást segíti az msdn.microsoft.com címen található XML 
tutorial gyűjtemény, amely a cikk által felszínre kerülő 
XML, XSL kérdésekre megnyugtató válaszokat nyújt. Termé- 
szetesen a levelezési listán is szívesen válaszolok. 
Végezetül hadd jelezzem, hogy az XSL fájlok nemcsak meg- 
jelenítésre valók, hanem ennél átfogóbb szerepük van: ál- 
talános XML transzformációra alkalmasak. Megfelelő mó- 
don alkalmazva az XSL-ek képesek A.XML-ből B.XML-t fa- 
ragni, ahol A.XML például egy autógyártó cég rendelési 
formátuma, míg B.XML egy alkatrészbeszállító cég gyártó- 
sorvezérlő adata. Ez azonban már egy másik történet: a 
BizTalk Server legendája... 


Fóti Marcell 
MCT, MCSE, MCDBA 











Server extensions 2. Tész 


Telepítés, adminisztráció és tervezés 

Az Office Server Extensions azért készült, hogy 
lehetővé váljon a munkacsoporton belüli való- 
di együttműködés, rendszerfelügyeleti oldal- 
ról pedig az volt a cél, hogy minél egyszerűbb 
legyen kezelni, s ahol lehet, használjuk ki a 
meglévő technológia előnyeit. Most a második 
részben az Office Server Extensions használatá- 
nak tervezésével foglalkozunk, megnézzük a tele- 
pítést és a felügyeleti funkciókat. További informáci- 

ók a Microsoft Office 2000 Resource Kit-ben olvashatók. 





A munkaállomások hardverigénye 

Olyan számítógépre van szükség, amely képes a Microsoft 
Office 2000-t, Netscape Navigator 3.0-t, az Internet Exp- 
lorer 3.0-t, vagy ezeknél újabbat futtatni. 


A munkaállomások szoftverigényei 

A használhatóság nagyban függ a Microsoft Office és a bön- 
böngésző szükséges. A Netscape Navigator-t vagy Internet 
Explorer 3.0-t használók az Office Server Extensions megbe- 
szélési és előfizetési funkcióit a Kezdőoldalon keresztül, a 
Discussions eszköztár keretekre épülő verziójával érhetik el. 
A Microsoft Office 2000-et és Internet Explorer 4.01-et 
használók közvetlenül az Office alkalmazásból vagy a bön- 
gészőből használhatják. Csak a DAV kiszolgálóra történő 
közzétételhez szükséges Internet Explorer 5.0. 


A kiszolgáló hardverigényei 

Az Office Server Extensions hardverigényei nagyban függe- 
nek az adott telepítési környezettől. Az egyidejűleg dolgo- 
zó felhasználók várható száma alapján számított igényeket 
a Microsoft Office 2000 Resource Kit tartalmazza. 


A kiszolgáló szoftverigényei 

"2 Windows NT Server vagy Workstation 4.0 Service Pack 
4-gyel, Internet Information Server 4.0 vagy újabb, a 
Windows NT Option Pack-ről telepített Index Server (a 
kereséshez) és Internet Explorer 4.01 vagy újabb. 

"B Microsoft Exchange Server vagy más SMTP levelezési ki- 
szolgáló a hálózatban (az értesítésekhez). 


Az Office Server Extensions telepítése 

Az Office Server Extensions olyan számítógépeken hasz- 
nálható, amelyek Windows NT Workstation-t vagy Server 
4.0-t vagy újabbat (Service Pack 4-gyel) futtatnak. A te- 
lepítés az Office 2000-éhez hasonlít, és felügyelet nélkü- 
li telepítésre is lehetőség van. 

A Telepítő az Office 2000 Telepítőtől független alkalmazás, 
neve Setupse.exe, és vagy a Microsoft Office 2000 Profes- 
sional-en (1. CD) vagy az Office 2000 Premium-on (3. CD) 
található meg. Ha az OSE telepítőt az Autorun.exe-ből fut- 
tatjuk a 3. CD-ről (Office Premium), az meghatározza, hogy 
rendelkezünk-e az OSE telepítésének feltételeivel - az In- 
ternet Explorer 4.01-gyel, a Windows NT Options Pack-kel 
és a Windows NT SP4-gyel - és segítséget nyújt ezen 








"Grie 


összetevők telepítéséhez. (Az OSE telepítőnek ez a funkci- 
ója nem használható az Office 2000 Professional-ből. ) 


TIZET] HEZEETT BET 


install Microsoft PhotoDraw 
Install Microsoft Office Server Extensions 


Bát 


Az OSE telepítő ezután azt a varázslót futtatja, amely beál- 

lítja az Office Server Extensions-t, és lehetővé teszi a 

Webkiszolgálón történő közzétételt, a webmegbeszéléseket 

és a webelőfizetéseket. A varázsló futása után a web készen 

áll arra, hogy az Office 2000 felhasználói együttműködjenek, 

Office dokumentumokat és weboldalakat tegyenek közzé. A 

Windows NT rendszergazda a telepítést egy varázsló segítsé- 

gével végzi el és a szokásos módon felhasználói nevet és li- 

cencinformációkat kell megadnia. Ezután a telepítés helyét 

jelöli ki. Az Office Server Extensions telepítés részeként a 

következő elemek némelyike vagy mindegyike települ: 

"0 FrontPage 2000 Server Extensions 

B Microsoft Data Engine (MSDE, de csak akkor, ha nincs a 
gépen SOL Server) 

"2 Windows Installer Service Pack. 

A telepítés végén a beállítási varázsló elkezdi a webkiszol- 

gáló bővítését az Office Server Extensions-szel. 


Server Extensions Configuration Wizard 


Welcome to the Server 
Extensions Configuration 
Wizard 


This wizard helps you configure an existing web server to 
use the Server Extensions. 


It cannot create a new web server. To create a new web. 
server that uses the Servet Extensions, use yout web servet 


"administration tools to create the server and then run this 


vizard again. 
Cíck Next to continue or Cancel to Exit. 


A varázsló olyan alapértelmezett értékeket tartalmaz, amelyek 
a legtöbb telepítés esetében használhatóak. Ezek után befe- 
jeződik az Office Server Extensions-t tartalmazó kiszolgáló be- 
állítása, és így alkalmassá válik arra, hogy segítségével az Of- 
fice 2000 felhasználói együttműködjenek és dokumentumokat 
tegyenek közzé. A rendszergazda a következőket állíthatja be: 
"8 Az adatbázis nevét és jelszavát, ha a Microsoft Data En- 

gine van telepítve. Ha a webkiszolgáló már rendelkezett 

korábban telepített SOL Server adatbázissal, egy meglé- 

vő SOL Server adatbázisnevet, SOL Server felhasználó- 
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nevet és SOL Server jelszót kell megadni. Ha a Micro- 
soft Data Engine adatbázisról SOL Server-re frissítünk, 
nincs szükség semmilyen beavatkozásra. 

"0 Létrejöjjenek-e felhasználói csoportok és rendszergaz- 
da fiók az NTFS adatvédelemhez. Ezzel üres rendszer- 
gazda (admin), szerző (author), böngésző (browser) és 
együttműködési (collaborator) csoportok jönnek létre 
az Office Server Extensions kiszolgálón. 

"0 Kiférjen hozzá a webmegbeszélés funkcióhoz. A már 

létrehozott, ismert Windows NT fiókok és csoportok ál- 

líthatók be, vagy mindenki - akár Windows NT fiók nél- 
kül is. Az alapértelmezés az ismert NT fiókok. 

Engedélyezzük-e az Internet Explorer-en kívüli böngé- 

szőket (alapértelmezés szerint engedélyezzük) . Ez a be- 

állítás egyúttal az alaphitelesítést is bekapcsolja. 

Engedélyezzük-e az AutoNavigation oldalakat a web- 

hez (alapértelmezés szerint engedélyezzük, és ezzel be- 

kapcsoljuk a könyvtárböngészést is). 

0 A levelezési beállításokat az előfizetéshez. 

A varázslóban megadott beállítások később az Office 
Server Extensions Administration Home Page használatá- 
val változtathatók meg. A varázsló beállításait meg kell 
adni az Office Server Extensions első futtatása előtt. Ha 
ezeket nem adjuk meg, az előfizetés és értesítés funkció 
nem működik a levelezési beállítások hiányos volta miatt. 


9; 


b 


Rendszerfelügyelet 

Az Office Server Extensions-t tartalmazó kiszolgáló karban- 
tartását az Office Server Extensions adminisztrációs eszkö- 
zei segítik, amelyek az Administration Home Page-ről elér- 
hető webalapú űrlapok. A FrontPage adminisztrációs esz- 
közökkel szabályozhatjuk, hogy egy munkacsoport-webre 
ki tehet közzé dokumentumokat. 











Adatvédelem 

Az adatvédelmet a Windows NT Server, az IIS, a FrontPage 
Server Extensions és az Office Server Extensions kombiná- 
ciója biztosítja. A Windows NT Server adatvédelem haszná- 
latához NTFS-t kell használni. 

Az adatvédelem beállítása az igényeknek megfelelően ki- 
szolgálónként különböző lehet. Az alábbiakban az adatvé- 
delem elemeinek szerepét tekintjük át: 
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2 Windows NT Server: Hozzáférést biztosít a kiszolgálók- 
hoz és a fájlmegosztásokhoz. NTFS használatával egye- 
di jogokat rendelhetünk a felhasználókhoz és csopor- 
tokhoz. A Windows NT User Managerrel, illetve Windows 
2000 esetén az Active Directory Users and Computers 
eszközzel hozhatunk létre felhasználókat és csoporto- 
kat, majd a megfelelő jogokat ezeknek adhatjuk ki. 
-2 Internet Information Server (IIS): Az IIS a böngészők 
felé biztosítja az adatvédelmet. 
3 
Fő? (ÁNONJIKŐUS BÖDVÉB EE ETT] 
No user name/password reguired to access this resource. 


Account used for anonymous access Edit... ] 
TAG E ELGÉ Éz EZ REESE e e S] 
For the following authentication methods. user name and password are 
reguired when 

anonymous access 


is disabled, or 
"access is restricted using NTFS access control lists. 
IT Basic authentication (password is sent in clear text) 
Select a default domain 
TT Digest authentication for Windows domain servers 


egi. 1 





A hitelesítés négy szinten állítható be: 

2 Az anonim (Anonymus) hitelesítéssel minden felhasz- 
náló hozzáférhet a webhelyszínhez, még azok is, akik 
nem rendelkeznek Windows NT fiókkal. (Ez tulajdon- 
képpen a hitelesítés kikapcsolását jelenti.) 

"8 Az alap (Basic) hitelesítés nem titkosítja a felhaszná- 
lónevet és a jelszót. A Basic hitelesítést sok webkiszol- 
gáló támogatja, az IIS továbbítani tudja a bejelentke- 
zést a Windows NT Server-nek. Ha a Basic hitelesítést 
a Secure Sockets Layer-rel (SSL) kombináltan használ- 
juk, a hitelesítés gyors és biztonságos lehet. (Az SSL 
titkosítja a továbbítást, így illetéktelenek nem tudják az 
adatokat olvasni.) 

"2 A Windows NT Challenge/Response (más néven NTLM, 
vagy integrated Windows) biztonságosabb módszer, 
mint az alaphitelesítés. Az NTLM nem működik tűzfa- 
lon keresztül, nem továbbítja a bejelentkezést másod- 
lagos kiszolgálóknak, és Internet Explorer 4.01-et vagy 
újabbat igényel. Ha a kiszolgáló Windows 2000, akkor 
Kerberos hitelesítés is történhet. 

"2 A Digest hitelesítés viszonylag új, szabványos forma, 
amelyet viszont csak az Internet Explorer képes egy- 
előre használni. 80-as porton kommunikál, így tűzfala- 
kon is keresztüljut. 

Lehetőség van arra, hogy mind az alap, mind a Windows 

NT Challenge/Response hitelesítést engedélyezzük. Ha a 

webböngésző támogatja a Windows NT Challenge/Respon- 

se-t, ezt a hitelesítési módszert, egyébként az alaphitele- 
sítést használja. Az IIS azt is lehetővé teszi, hogy egyes 

TCP/IP címeket (vagy számítógépeket) letiltsunk. Ha min- 

den felhasználó Internet Explorer 4.01-et vagy újabbat 

használ, az alaphitelesítést kikapcsolhatjuk. A Netscape 
nem támogatja az NTLM-t, így az ilyen felhasználók igény- 
lik az alaphitelesítés meglétét. 


; 
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0 FrontPage Server Extensions: Mind a FrontPage, mind 
az Internet Information Server lehetővé teszi, hogy a 
rendszergazda több különálló webhelyszínt hozzon lét- 
re egy kiszolgálón. A FrontPage azt is lehetővé teszi, 
.hogy minden webhez különböző adatvédelmi szerepet 
állítsunk be: böngészőt, szerzőt vagy rendszergazdát. A 
FrontPage-dzsel egy weben belül alwebeket is létrehoz- 
hatunk, amelyekkel az adatvédelem tovább szabályoz- 
ható. Például egy webhelyszín az egész vállalat számá- 
ra nyilvános, de egy éppen létrehozás alatt lévő doku- 
mentumhoz csak egy adott munkacsoport férhet hozzá. 

"0 Office Server Extensions: Az Office Server Extensions 
telepítésekor minden webhez speciális felhasználói 
csoportok is telepítődnek, melyek egymásra épülnek - 
az együttműködő böngészhet és csoportmunkában ve- 
het részt, a szerző pedig dokumentumokat írhat, cso- 
portmunkában vehet részt és böngészhet. Az admin, 
author és browser csoportok megegyeznek a FrontPage 
Server Extensions-ben beállítottakkal - az Office Server 
Extensions az collaborator szerepet a megbeszélési 
funkcióhoz használja. A collaborator szerep lehetővé 
teszi, hogy a felhasználók csoportjainak anélkül adjunk 
jogot a w ebmegbeszélésekben való részvételre, hogy az 
egész webhez korlátlan hozzáférést adnánk nekik. 

Az Office Server Extensions tehát a Windows 2000 Server 
adatvédelmére és a FrontPage Server Extensions szerepek- 
re osztott adatvédelmi modelljére épít. Amikor az Office 
Server Extensions-t telepítjük a webkiszolgálóra, a rend- 
szergazdának csak felhasználókat és csoportokat kell adnia 
az Office Server Extensions author és/vagy admin csoport- 
jaihoz. Az alapértelmezések használata esetén a böngésző 
és együttműködő csoportokhoz az Everyone (mindenki) 
csoport, az admin csoporthoz pedig a LOCALMACHINEVAd- 
ministrators csoport adódik. 


Javaslat a Webkiszolgáló engedélyeinek kiadásához 

Az Office-szal bővített biztonságos webkiszolgáló telepíté- 
sének legegyszerűbb és legkönnyebb módja az, ha a Win- 
dows NT Challenge/Response-t (NTLM) használjuk. Az 
NTLM egyszerűvé teszi a bejelentkezést, elegendően biz- 
tonságos hitelesítési módszer, viszont csak Internet 
Explorer-rel használható. Ha néhány felhasználó nem ren- 
delkezik Internet Explorer 4.01-gyel vagy újabbal, telepít- 
sük mind az alap, mind a Windows NT Challenge/Response 
hitelesítést. Ez az Office Server Extensions alapértelmezett 
beállítása. A használandó módszert a kiszolgálóhoz hozzá- 
férő böngészők alapján választhatjuk ki. Ezután a felhasz- 
nálókhoz egyedi jogokat úgy adhatunk, hogy a FrontPage- 
dzsel további webeket telepítünk. 

Néhány webhelyszín ennél jobban szabályzott adatvédel- 
met igényel. A FrontPage beépített biztonságkezelő funk- 
cióinak kikapcsolásával a FrontPage-dzsel bővített webre 
kézzel is beállíthatunk engedélyeket. 
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A webmegbeszélések adminisztrálása 

A webmegbeszéléseket az Office Server Extensions Confi- 
gure Web Discussions Settings oldal használatával engedé- 
lyezhetjük és tilthatjuk le. 

Azt is meghatározhatjuk, hogy a felhasználók részt vehet- 
nek-e távoli kiszolgálók dokumentumairól szóló megbeszé- 
léseken. Alapértelmezésként az Office Server Extensions 
engedélyezi ezt, de ez az adatbázis méretének csökkenté- 
se érdekében korlátozható. Az adatbázis méretének csök- 
kentése az automatikus törlés (Automatic Deletion) hasz- 
nálatával is elvégezhető. Ekkor a megbeszélési elemek a 
megadott idő elteltével automatikusan törlődnek. A rend- 
szergazda a megbeszélésre használható dokumentumok lis- 
táját is megtekintheti, majd kézzel is törölhet elemeket. 


A webelőfizetések és értesítések adminisztrálása 

A webelőfizetéseket az Office Server Extensions Administ- 
ration Home Page használatával engedélyezhetjük vagy 
tilthatjuk le. Ha engedélyezzük a webelőfizetéseket, meg 
kell adnunk annak az SMTP levelezési kiszolgálónak a ne- 
vét, amely a leveleket küldeni fogja, valamint be kell állí- 
tanunk a használni kívánt küldő és címzett címeket is. Azt 
is meghatározhatjuk, hogy a felhasználók milyen időközö- 
ket választhatnak az értesítési e-mail fogadására. Beállít- 
hatjuk, hogy a módosítástól számított pár percen belül, 
naponta egyszer vagy hetente egyszer kapjanak levelet. Az 
is beállítható, hogy mikor küldődjön el - ha az értesítési 
e-mail-t csúcsidőn kívülre időzítjük, a küldést nem zavarja 
más hálózati forgalom. Az aktív előfizetéseket is megte- 
kinthetjük, különböző szempontok szerint szűrhetjük és 
szükség szerint egyes előfizetéseket törölhetünk is. 

Ha nem rendelkezünk SMTP kiszolgálóval, vagy fontos az 
adatvédelem, ezt a funkciót letilthatjuk. 


Fejlett rendszerfelügyelet 

A Windows NT, az Internet Information Server és a Front- 

Page Server Extensions további felügyeleti eszközöket is 

tartalmaz: . 

"b Performance Monitor: Valósidejű kiszolgáló-statiszti- 
kák összegyűjtéséhez a Microsoft Database Engine-en 
vagy az IIS-en. 

2 FrontPage Server Administration Tools: Az adatvéde- 
lem kezeléséhez, alwebek létrehozásához és kezelésé- 
hez, a közzétételi funkciók engedélyezéséhez és letil- 
tásához és egyéb FrontPage webfunkciókhoz. Az eszkö- 
zök különböző formátumúak lehetnek - MMC snap in, 
parancssori és Windows alkalmazás. Az egyik ilyen 
funkció például egyszerűvé teszi az Office Server Ex- 
tensions további webekhez adását, és az adminisztrá- 
ciós beállítások megváltoztatását. 

"2 HTML kód: HTML kóddal és az Office Server Extensions 
objektummodellel az AutoNavigation oldalak testre 
szabhatók. 
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Tervezési szempontok 

Ha az Office Server Extensions-t kis munkacsoportban hasz- 

náljuk, a tervezés igen egyszerű. Ellenőrizzük, hogy a szá- 

mítógépek megfelelnek-e a rendszerigényeknek és hogy 
megfelelő engedélyekkel rendelkezünk-e a szoftver telepí- 
téséhez és karbantartásához. 

Nagyobb szervezetben egy kicsit körültekintőbben kell tervez- 

nünk, különösen a webmegbeszélések esetében. Itt az adatvé- 

delmet és a teljesítményt kell megvizsgálni. Az Office Server 

Extensions telepítésekor a következőket kell megtervezni: 

"0 Rendszerigények: A Microsoft Office 2000 Resource Kit 
használatával ellenőrizzük, hogy a hardver kielégíti-e 
az egyidejű felhasználók számához igazodó igényeket. 
Azt is ellenőriznünk kell, hogy rendelkezünk-e a szük- 
séges szoftverekkel és service pack-ekkel. 

"0 Funkciók: Mely funkciókat akarjuk engedélyezni? Le 
akarunk-e tiltani bizonyos funkciókat? 

"I Webmegbeszélések: Le akarjuk-e töröltetni automati- 
kusan a régi megbeszéléseket? Engedélyezzük-e a tá- 
voli dokumentumokkal kapcsolatos megbeszéléseket? 

0 Előfizetés és értesítések: Rendelkezünk-e SMTP levele- 
zési kiszolgálóval? Ha nem, egyszerűen telepíthetjük. 
Felmerülnek-e adatvédelmi problémák, ha egy felhasz- 
náló előfizethet olyan mappára, amelyhez nem rendel- 
kezik olvasási engedéllyel? 

0 Adatvédelem: Az Office Server Extensions author, 
browser és collaborators csoportjaihoz megfelelő fel- 
használói csoportok adásával használjuk ki a már meg- 
lévő adatvédelmet. Ha a web egyes részei ettől külön- 
böző adatvédelmet igényelnek, hozzunk létre még egy 
webet. Döntsük el, hogy az együttműködők csoportnak 
alaphitelesítéssel adunk-e helyi bejelentkezési jogot. 
Döntenünk kell az együttműködők szerepéről is. Alap- 
értelmezésként a beállítási varázsló mindenkinek 
együttműködési hozzáférést ad. Ha ezt el akarjuk ke- 
rülni, a beállítást az Office Server Extensions telepíté- 
sekor kell megváltoztatnunk. Később ez csak kézzel vé- 
gezhető el. Mivel az AutoNavigation oldalak a könyv- 
tárböngészés engedélyezését igénylik, ez az alapértel- 
mezés. A nagyobb biztonság érdekében a könyvtárbön- 
gészést és az alaphitelesítést ki is kapcsolhatjuk. 

0 A megbeszélési adatbázis: Ha a webkiszolgálón már 
rendelkezünk SOL Server adatbázissal, és a mentéshez 
és a karbantartáshoz ki akarjuk használni a meglévő 
beállítások előnyeit, az SOL Server-t használjuk az 
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adatbázishoz. Ha nincs SOL Server, az Office Server Ex- 
tensions a Microsoft Data Engine adatbázist telepíti. 
Ha egy távoli SOL Server adatbázist akarunk használni 
és SOL Server még nincs helyileg telepítve, a telepítőt 
a ,no database" paraméterrel futtassuk, és az adatbá- 
zist később határozzuk meg. 


Integráció a FrontPage Server Extensions-szel 

A FrontPage Server Extensions a webkiszolgáló olyan prog- 

ramjainak készlete, amely a felhasználók számára lehetővé 

teszi, hogy a FrontPage alapú webet - amely a webhely- 
színt felépítő oldalakat, képeket, alkönyvtárakat és egyéb 
fájlokat tartalmazza - távolról adminisztrálják. A FrontPa- 

ge Server Extensions emellett azt is lehetővé teszi, hogy a 

felhasználók a weboldalakon dinamikus funkciókat (példá- 

ul számlálókat és űrlapkezelőket) alkalmazzanak. A Server 

Extensions a szabványos webkiszolgáló bővítő felületeket 

(például a CGI-t és az ISAPI-t) használja, és gyakorlatilag 

minden elterjedt webkiszolgálóval használható. 

"0 Az Office Server Extensions a FrontPage Server Exten- 
sions-re épül, mely képes például a Webhelyszín dokumen- 
tumaiban automatikusan karbantartani a hivatkozásokat. 

Talán szomorú hír, de tapasztalati tény, hogy az OSE tele- 

pítő sajnos nem tud mit kezdeni az SOL Server 2000-rel, és 

verzióhibákra hivatkozva nem képes elkészíteni az OSE 
adatbázist. Így sajnos egyelőre marad az MSDE, vagy az 

SOL Server 6.5 és 7.0 használata. 


Server Extensions Configuration Wizard " A 
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The Configuration Wizard was unable to connect to the Microsoft SOL Server "a! due to version 
incompatibilíties, If you wish to continue, you will have to manually create the database on that 


server before continuing. Would you like to use this server? 
Selecting NO will allow you to modify your settings. 


(zeszzl Ess] 


Ez a bosszantó mellékkörülmény elkerülhető, ha a Server 
Extensionst az SOL Server telepítése előtt tesszük fel, így 
nem talál rá a meglévő SOL Serverre, és felteszi az MSDE- 
t, amit azután egyszerűen frissíthetünk SOL 2000-ré. A má- 
sik megoldás az lehet, hogy - tekintettel az SOL Server 
2000 többpéldányos telepítési lehetőségére, és arra, hogy 
akár párhuzamosan is futni képes egy 7.0 verzióval - SOL 
Server 7-re telepítjük, majd onnan a beépített Data Trans- 
formation Services segítségével áthúzzuk a kitöltött adat- 
bázist a 2000-es adatbáziskezelőre. 






Ilyen még nem volt, de ha sikeresnek ígérkezik, akkor legközelebb is lesz: válaszoljon az alábbi négy 

kérdésre, és ha szerencséje van, bekerül azon boldog IT guruk körébe, akik már rendelkeznek NetAcade- 

mia bögrével. A bögretulajdonosok arról híresek, hogy valahol, valamikor egyszer valami nagyon okosat 

mondtak, s ezt honoráltuk Magyarország talán leginformatikusabb bögréjével, mely hatalmas befogadó- 

képességének köszönhetően fél literig skálázható. 

1. Mit jelent az XML leírónyelvben a cbill: tag? 

2. Miért nem érdemes az Exchange Server 5.5 telepítésénél meghagyni a felkínált 
Administrator fiókot, mint Site Service Account felhasználót? 

3. Mi a baj a régi típusú "- illesztő operátorral? 

4. Mitől sokkal jobb választás a Windows 2000 beépített Kerberos azonosítása 
mint a hagyományos NTLM akármelyik verziója? 

A válaszokat a http://technet.netacademia.net oldalon, a novemberi számhoz tartozó lapon várjuk szeretettel a 
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Miért kemi nak ki a PC-k? 


A számítástechnikai eszközök ezerféle alakba fog- 
nak megjelenni, de mindig szükség lesz általános 
célú számítógépekre. 
A személyi számítógépek korszakának vége - 
halljuk évről évre a sajtóban, majd a PC eladá- 
sok ismét minden várakozást felülmúlnak. Ebben 
az évben ugyanez történt. Az első negyedév el- 
adási előrejelzései igen kilátástalannak tüntették 
fel a piacot, azt hihettük: most már tényleg vége. 
Valójában az egész évre vetített adatok egészséges, 
199o-os növekedést mutatnak. Több, mint százmillió PC-t ad- 
tak el például 1999-ben, ez azt jelenti, hogy legalább annyi 
személyi számítógép kel el, mint amennyi színes televízió. 
A PC mindenkinek kezébe adja azt 
a számítási teljesítményt, ami 10 
évvel ezelőtt kizárólag nagyvállala- 
tok számára volt elérhető. Azonban 
az emberek ezt már teljesen termé- 
szetesnek veszik - és még többet 
akarnak. A PC szolgáltatásai min- 
dennapjaink részévé váltak, emiatt 
ezeket a mai ember mindenütt hasz- 
nálni szeretné függetlenül attól, hogy éppen hol tartózkodik, 
vagy milyen eszköz áll rendelkezésére - palmtop, webes tele- 
fon, autó PC, vagy webTV - egyre megy. Okos szoftverekkel, 
erőteljes processzorokkal, drótnélküli kommunikációval ren- 
delkezünk - ez a kívánalom hamarosan teljesíthetővé válik. A 
legtöbbünk számára nyilván a 
PC marad az elsődleges mun- 
kaeszköz, hisz továbbra is 
szükségünk lesz nagyméretű 
kijelzőre és normális billentyű- é 
zetre levélíráshoz, webböngé- hess; 
széshez, és ugyanígy szükség lesz a processzorok hatalmas 
teljesítményére házi digitális fotólaborunk, és a család ked- 
venc játékprogramjai számára. Azonban a jövő az együttmű- 
ködő számítógépeké. Eszközeink képessé válnak majd arra, 
hogy naptárunkat, elektronikus leveleinket, címlistáinkat tö- 
kéletesen átvigyük egyik géptípusról a másikra, s még csak 
vesződnünk sem kell majd a beállításokkal, hisz mindez au- 
tomatikusan fog megtörténni. Ha meg szeretnénk tudni egy 
z új autó legkedvezőbb beszerzé- 
si árát, majd azonnal le szeret- 
nénk ellenőrizni bankszámlán- 
kat, hogy vajon elegendő pénz 
van-e rajta a vásárláshoz, ezt 
mind megtehetjük majd azzal 
az eszközzel, amit mindenhova magunkkal fogunk hordani - 
nem nevezném e készüléket telefonnak. Akárhol vagyunk, 
akármilyen információra van szükségünk, hozzá fogunk férni! 
Ezzel egy időben - ne tévesszük szem elől a trendeket - a PC- 
k egyre erőteljesebbé, megbízhatóbbá, és egyszerűbben 
használhatóvá válnak. Történik mindez annak ellenére, hogy 
a bennük lévő hardver és szoftver egyre bonyolultabbá válik, 
ez a ,bonyodalom" már nem jut el a felhasználóig, nem fog- 
ja őt állandóan zaklatni. Hozzánk igazodó felhasználói felü- 
letek jelennek meg hangfelismeréssel élő nyelvi vezérléssel. 
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Természetesen azonnal rendelkezésre fognak állni, ahogy be- 
kapcsoljuk őket (instant on), I" 
és nem kell majd perceket / 
várni a bootolásra. A PC válik 
az otthoni hálózat központ- 
jává (esetleg egy nagyobb ki- 
szolgálóhálózat részeként, 
mely  teljesítményfigyelést, : 
szoftverfrissítést és egyéb nyalánkságokat nyújt automatiku- 
san) és természetesen mindennél egyszerűbb lesz a kezelése. 
Azután tanúi lehetünk majd a PC-k alakváltozásának, hisz 
minden alkatrész egyre kisebbé és kisebbé válik: a Tablet PC 
alakját például egyértelműen a kijelző, s nem a többi hard- 
vereszköz mérete és formája határozza meg. 

Ez a modell létfontosságú szerepet játszik a jövő , mindent- 
mindenhol" számítástechnikájában. A személyi számítógépek 
alacsony árnagy volumen 
megközelítése át fog ter- 
jedni eme kis masinák pi- 
acára is. Az innovációk, 
újítások ekkor simán kifi- 
zetődnek, még jobban, 
mint a mai kis sorozatú, 
ám horribilis árú kézi esz- 
közöknél. A széleskörűen 
elfogadott szabványokon alapuló eszközökről pedig már a vá- 
sárlás pillanatában tudni fogja a boldog tulajdonos, hogy ma- 
sinája együtt fog működni meglévő eszközeivel. A PC-plus vi- 
lágban a kommunikációé a főszerep, így a szabványok köve- 
tése teljesen természetes és logikus lépéssé válik. 

A PC-k teljesen új utat mutattak a világnak abban, so3zat 
is kell hatékonyan dolgozni, 
kommunikálni és önfeledten 
szórakozni. A PC-plus korszak 
legalább ekkora forradalmat 
hoz: A PC-k ereje a világ 
minden zugában elérhetővé 
válik olyan eszközökkel, a- 
melyekről még csak álmodni sem merünk. Az én pozícióm- 
ban talán meglepő hogy így lelkesedem. A Microsoft jövő- 
jét bizony erre a lapra tettem fel! 
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ESA. Microsoft Back Office? Family Member 


1994-ben ismerkedtem meg a Microsoft SOL 
Server-rel, 4.Oa volt a verziószáma. Mai szem- 
mel nézve persze döbbenetesen primitív volt, 
ám már akkor is rendelkezett azokkal a képes- 
ségekkel, amelyek miatt az ember örömmel 
dobta el a Clipper-t: tranzakciókezelés, ügy- 
fél-kiszolgáló felépítés, többszálú végrehajtás 
stb. Félelmetesen összetett banki rendszere- 
ket készítettünk akkoriban 486DX4-100 pro- 
cesszoros, 16 megabájt memóriával felvértezett , szervereken". Az el- 





múlt évek során az SOL Server megfiatalodott: fürge lett és erős. S 
ahogy verzióról verzióra fiatalodott, úgy vált egyre okosabbá is. Zseni- 
ális lekérdezés optimalizálója segítségével szakavatott kezekben szár- 
nyakat kap. A TPC-C teljesítménytesztek világbajnoka rendszerfelü- 
gyeleti szempontból is kiváló termék. A 7.0 már lehetővé tette az adat- 
bázis által összegyűjtött adatok okos elemzését, hisz megjelent benne 
az OLAP kiszolgáló. S ami napjainkban lázba hoz, az a mesterséges in- 
telligencia határmezsgyéjén található adatbányászat. Az adatok rejtett 
összefüggéseinek feltárása minden adatbázis tartalmát életre kelti. A 
december elején a NetAcademia Kft, a BST Kft. és a Microsoft Magyar- 
ország közös szervezésében megrendezésre kerülő 


SOL Server Napon 


Megpróbálok valamennyit átadni azokból a tapasztalatokból, melyek 
az évek során ,rám rakódtak". Természetesen egyetlen nap nem lehet 
elegendő a teljes információhalmaz átadására. Mindenkit szeretettel 
várok SOL Server 2000 tanfolyamaimon, melynek helyszíne a Business 
Software Training Hivatalos Microsoft Oktatóközpont (CTEC). 


Business 
, Software 
"Training 





Jelentkezés a konferenciára és 
részletes tudnivalók a 
http://www.netacademia.net/SOLna 
vagy 
http://www.bst.hu/SOLna; 


címen! 


Az SOL Server nap rövid tematikája a következő: 


e Adatbázisok a rendszergazda hozzáértő kezé 


ben. Azaz mi mindent tehetünk a teljesítmény fo- 
kozása érdekében még akkor is, ha készen vett al- 
kalmazással van dolgunk? 


e Az SOL 2000 újdonságai programozók számára. 
Ismerkedjünk meg az SOL 2000 fejlesztőknek szóló 
fantasztikus újdonságaival: XML támogatás, fel- 
használói függvények, indexelhető nézetek, inste- 
ad-of triggerek, Kaszkád referenciális integritás 


e Adatbányászat A mesterséges intelligencia 
határmezsgyéjén húzódó technológia az adatok kö- 
zött megbúvó rejtett összefüggések feltárására. 


e Online Analitical Processing. Adatelemzés 
mesterfokon 


Hivatalos SOL 2000 Server vizsgaelőkészítő tanfolyamok a 
NetAcademia Kft. és a Business Software Training Hivatalos Microsoft Oktatóköz- 
pont (CTEC) közös szervezésében! 


2072 Administering a Microsoft SOL Server Database, 
5 nap. Időpontok: 2000 november 20-24, 2001 január 22-26 


2073 Programming a Microsoft SOL Server Database, 5 napidőpontok: 2000 november 6-10, 2001 február 5-9 


Jelentkezés: 
www.netacademia.net/tanfolyamok illetve www.bst.hu 





A legjobbakat tanítjuk. 
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